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(57) A graphical solutions development system us- 
ing placement of blocks representing hardware/soft- 
ware functionality on a computer screen tibio drawing 
and connecting the blocks by wires representing data 
and control flow to create application programs and/or 



hardware design. The blocks are instances of develop- 
ment tibio components which include intelligence for op- 
timization within a detected environment. This permits 
effective programming of digital signal processors and 
system design by users not expert in digital signal 
processing programming and system design. 
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Description 

[0001] The Invention relates to electronic devices 
and, more particularly, but not exclusively, to software 
and hybrid hardware/software development and sys- 
tems and methods. 

[0002] The expanding use of computers and embed- 
ded processors increasingly demands customized ap- 
plications specific to the requirements of particular us- 
ers. This has led to the widespread employment of vis- 
ual builder tools for creating custom application pro- 
grams thro ucjh the interlinking of software modules from 
libraries. 

For example, Visual Basic for Applications from Micro- 
soft Corporation and C++ Builder from Borland Interna- 
tional provide visual environments which have a graph- 
ical user interface (GUI) and include a toolbox with dif- 
ferent classes of components (software mdules), form 
windows for combining components visually, and prop- 
erty sheets for the components which can be modified 
to customize the components. 

(JSP 5,850,548 and USP 5,950 : 001 illustrate variations 

of visual development environments. 

However, the known visual development methods have 

problems including limited component intelligence and 

flexibility. 

[0003] Viewed from a first aspect, the present inven- 
tion provides a graphical development system for soft- 
ware/hardware hybr ds with intelligent development 
components appropriate for real-time processors plus 
development framework rules to ensure development 
component object optimization within the resulting ap- 
plication program. This has advantages including pro- 
gram development of digital signal processor applica- 
tions by non-specialisl programmers. 
[0004] Embodiments of the invention will now be de- 
scribed, by way of example only, with reference to the 
accompanying drawings, in which: 
[0005] The drawings are heuristic for clarity. 
Figures 1-5 show computer systems and software in 
block form. 

Figure 6 is a screen shot illustrating generic screen el- 
ements. 

Figure 7 shows preferred embodiment graphical solu- 
tions development system in block form. 
Figures 8A-8D are aspects of a development compo- 
nent. 

Figure 9 illustrates a development drawing. 
Figures 1 0A-10C show aspects of real-time operation. 
Figure 11 is a hardware component. 
Figure 12 illustrates programmable logic component. 
Figure 13 shows annotation component. 
Figures 14A-14B show a user interface and block draw- 
ing. 

Figure 1 5 is a property dialog window. 

Figures 16A-16C illustrate multiple code modules in a 

development component. 

Figures 1 7A-1 7J show a development drawing, property 



dialogs, and code. 

Figure 18 is a development component gallery. 
. Figures 19A-19E illustrates a development framework. 
Figures 20A-20F show a development component pub- 
5 lisher. 

Figure 21 illustrates a framework rule. 

Figures 22A-22C show a development drawing and 

probes. 

Figure 23 is an example of environment inquiry code. 
10 Figure 24 shows file structure. 

Figures 25A-25F illustrate development component 
scripts. 

Overview 

15 

[0006] The preferred embodiments provide a graphi- 
cal solutions development system (integrated develop- 
ment environment) with a library of development com- 
ponents (called "tibio components" to distinguish from 

20 the many other uses of "component") which, in addition 
to software code for performing their functionalities, also 
include design information and environmental detection 
for automatic optimization. Figure 7 shows a block dia- 
gram. Hybrid hardware/software functionalities are in- 

25 eluded in the solutions that can be developed. The typ- 
ical application developed runs on a real-time processor 
such as a DSP plus, possibly, concurrently on a general- 
purpose processor (e.g., an ARM) and may communi- 
cate with a host processor. Frameworks for the graph i- 

30 cal programming development ("tibio frameworks") in- 
clude constraints to insure automatic optimization. 

General Architecture 

35 A. General 

[0007] The first preferred embodiment development 
systems may be implemented on a main computer sys- 
tem such as the system 100 of Fig.1. System 100 in- 

40 eludes at least one central processor 1 01 , a main mem- 
ory system 102, a keyboard 103, an input/output con- 
troller 104, a display device 105, a pointing device 106 
(e.g. a trackball, a mouse, or a pressure-sensitive tablet 
with corresponding pen device), and a mass storage de- 

45 vice 107 (e.g. a hard-disk drive). System 100 may also 
include peripheral devices such as a printer 1 08, a plot- 
ter 109, a local area network (LAN) connection 110, a 
modem 111 , and a sound card 112. 
[0008] As shown in Fig. 2, computing system 1 00 may 

50 include one or more secondary (or target) processing 
systems 201 , where each secondary processing system 
may or may not be in physical proximity to the main com- 
puting system. Further, the secondary processing sys- 
tem may or may not be electrically connected to the 

55 main computing system. For purposes of clarification, 
and if desired, connections 202 between the main com- 
puting system and the target computing system may be 
implemented in a number of different ways, which in- 
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elude but are not limited to: direct electrical connection 
via a serial cable, direct electrical connection via a par- 
allel port cable, direct electrical connection via a . univer- 
sal serial bus (USE) cable, connection via optical fiber, 
connection via a local area network, connection via the ■ s 
Internet (or other wide area network), connection via ra- 
dio frequency (RF) communication channel, or via direct 
connection to a shared bus or shared memory. 
[0009] Illustrated in Fig. 3, a secondary processing 
system 201 is comprised of at least one central process- to 
ing unit 301 which may include (or be electrically con- 
nected to) a memory subsystem 302, an input/output 
system 303, and other miscellaneous hardware 304. 
The central processing unit 301 on a secondary process- 
ing system is not required to match the processing unit 15 
1 01 on the main computer system 1 00. Also, in instanc- 
es where there is more than one secondary processing 
system, the central processing units 301 on the second- 
ary processing systems may be identical, or similar, or 
completely different. Each secondary processing sys- 20 
tern may execute a single dedicated task, or may exe- 
cute a variety of tasks under the supervision of an op- 
erating system (or the functional equivalent of an oper- 
ating system). 

[0010] The main computer system 100 is equipped 25 
with a software system 400 that directs the operation of 
the main computer. As shown in Fig. 4, software system 

400 includes an operating system (OS) 401 that pro- 
vides a set of basic system services. The software sys- 
tem is frequently stored on a hard disk drive 107 and 30 
essential pieces of the software system are loaded into 
random-access memory (RAM) as they are needed. 
Some portions (or all) of the software system may be 
accessed via a local area network, the Internet, or other 
remote means. In the preferred embodiments the main 35 
computer system 100 includes a graphical user inter- 
face 404 for receiving user commands and to provide 
feedback (or results) to the user. In a typical scenario, 

the user interface is provided by application software 
such as application software or windows application 40 
software 403. This graphical user interface is normally 
provided, by the application and/or the windows shell 
402 that runs on a suitable operating system 401 . In one 
embodiment, Microsoft Windows NT (aka Windows 
2000) implements both the operating system 401 and 45 
the windows shell 402. 

[0011] Fig. 5 illustrates the main computer system 
100 equipped with a preferred embodiment graphical 
solutions development system (GSDS) 500 to assist us- 
ers in the task of creating software programs. As shown, 50 
the graphical solutions development system interfaces 
to the main computer system, as well as to various sec- 
ondary processing systems, via the operating system 

401 and the windows shell 402. 

55 

B. Graphical User Interface 

[0012] As shown in Fig. 6, the main computer system 



100, in concert with the operating system 401 , the pre- 
ferred embodiment graphical solutions development 
system (GSDS) typically presents a user interface 600 
as a visual workspace for developing solutions projects. 
The visual workspace 600 is suitable for displaying fully 
annotated graphical drawings (called "tibio drawings") 
including block diagrams for electrical hardware and 
block diagrams of software. The user interface 600 may 
be rectangular or may be presented using other shapes. 
In general the main user interface 600 presents the fol- 
lowing visual interactive elements: titlebar 601 , menu- 
bar 602, toolbar 603, client area 604, statusbar 608, as 
well as both vertical scrollbars 605 and horizontal scroll- 
bars 607. The main user interface 600 may be resizable 
or may have fixed screen dimensions. 
[0013] A screen cursor 606 is normally provided by 
the windowing system or operating system, but it may 
be implemented in the application. The screen cursor 
606 moves on the screen corresponding to movement 
of the pointing device 106. This provides the user with 
a convenient means of graphically accessing screen ob- 
jects and also provides a means for controlling objects 
represented on the screen. The screen cursor 606 can 
provide additional information to the user by changing 
color or shape. Before, during, or after moving the cursor 
(via movement of the pointing device) . the user may 
generate user-event signals (e.g. mouse, "clicks" or 
"drags") that represent commands to the graphical so- 
lutions development system. Various user operations 
are accessed via either mouse operations or keyboard 
103 entries. For convenience many user operations 
may be accessed in more than one way (e.g. "copying" 
a tibio drawing block by "clicking" on the "Copy" icon 
located oh the toolbar 603, entering keystrokes via the 
keyboard 103 to access the "Edit" menu, or using key- 
stroke accelerators ("hot-keys") to invoke a copy oper- 
ation). 

[0014] The titlebar 601 normally presents text that 
gives both the name of the application (e.g. "TIBIO 
CAT") and the current tibio drawing name (e.g. 
"Examplel .tib"). 

[0015] The menubar 602 provides access to a set of 
drop-down menus that provide many useful functions 
like adding components to the tibio drawing, saving the 
tibio drawing, and configuring the target hardware. 
[0016] The toolbar 603 provides a row of icon-buttons 
to permit rapid access to functions that are most com- 
monly used. In ihis example, the toolbar functions from 
left to right are: new tibio drawing, open a file, save the 
tibio drawing, cut, copy, paste, add a component to the 
tibio drawing, build, run, stop, reset the target hardware, 
add a probe : add an audio probe, and lastly, turn on the 
data viewer. It is common to provide more than one tool- 
bar. 

[0017] The client area 604 is available to the user to 
construct (or present) block tibio drawings that repre-. 
sent solutions. The actual dimensions of a tibio drawing 
may exceed the client area 604; the scrollbars 605, 607 
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permit the user to access portions of the tibio drawing 

that may not otherwise be visible. 

[001 8] The statusbar 608 is portion of the screen that 

is handy for posting short status messages and status 

icons. 

[0019] The user has the option to suppress or make 
visible the menubar 602, the toolbar 603, and the sta- 
tusbar 608. 

Visual Development Environment 
A. Overview 

[0020] The preferred embodiment graphical solutions 
development system 500 comprises a graphical pro- 
gramming environment that facilitates rapid solution de- 
velopment through the use of pre-engineered tibio com- 
ponents. The client area 604 provided by the graphical 
solutions development system 500 represents a piece 
of paper where the user may "draw" (i.e. draft) a solu- 
tion. The resulting user-generated tibio drawing 609 rep- 
resents a solution, which may be an aggregate of both 
hardware functions and software functions. The graph- 
ical solutions development system 500 provides a rich 
set of resources to assist in building a solution. These 
resources include a variety of tibio components, means 
to interconnect tibio components (referred to as "wires"), 
and many others. These resources effectively permit a 
user to "draw" a "block diagram" in the client area 604 
on the main computer display 1 05. This enables the user 
to "draw" a block diagram (on a computer screen) com- 
prised of distinct software functional units as well as dis- 
tinct hardware functional units. 

[0021 ] The resulting block diagram is referred to as a 
tibio drawing 609. 

[0022] There are several terms and constructs that 
have specific definitions in the graphical solutions de- 
velopment environment. 
These are nominally defined as follows: 
Terminology used in the description includes the follow- 
ing: 

Block: an instance of a tibio component; maintains per- 
sistent property information. A block nominally repre- 
sents a functional unit, which may include a software 
function or algorithm, a hardware function, and/or some 
other functionality. 

Tibio component: a self-contained deployable unit of pri- 
mary functionality. Primary functionality refers to, but is 
not limited to, algorithms s mathematical functions, and 
control functions, which may be executed in either hard- 
ware or software. 

A tibio component may also contain resources that pro- 
vide secondary functionality, such as configuration, 
help, etc. 

Tibio component Gallery: an applet provided by the in- 
tegrated development environment (IDE) that provides 
a sorted list of available tibio components or tibio com- 
ponent-tokens 



Tibio component-Token: a tibio component featuring re- 
stricted primary functionality. A tibio component-token 
may be distributed for marketing or promotional purpos- 
es. The primary functionality of a tibio component-token 
5 may be totally void, it may be partially disabled, or it may 
be provided via an emulator. 

Tibio drawing: the visual representation of a block dia- 
gram on the display screen. 

Tibio framework: a collection of rules and a software ap- 

10 plet that can check for rule violations. 

Pin: an abstraction for the input connection points to or 
output connection points from a tibio component. 
Platform: an abstraction that represents a target hard- 
ware assembly. 

15 ' Probe: an abstraction for an oscilloscope (or other) 
probe. 

Project: an abstraction for the software associated' with 
a single processor. 

Viewer: an applet that provides a visual (or other sen- 
20 sory) representation of data. 

Wire: an abstraction for visually denoting data or control 
flow. 

Workspace: an abstraction for a collection of software 
projects. 

25 [0023] Fig. 7 provides an overall block diagram of the 
graphical solutions development system 500. Because 
the ultimate goal is to provide the user with a powerful 
graphical design capability based on pre-engineered ti- 
bio components, the initial task is to provide the ability 
30 to create compatible tibio components. The tibio com- 
ponent publisher 501 is an applet designed to create ful- 
ly compatible tibio components 502. The tibio compo- 
nent publisher 501 creates a sequence of dialog win- 
dows (i.e. a wizard) that is designed to gather relevant 
35 information from the user regarding the tibio component 
being published. Information supplied by the tibio com- 
ponent creator may include the name of the tibio com- 
ponent, the date of publication, the revision number, re- 
sources that need to be included to assure primary func- 
40 tionality, interfaces, and other miscellaneous items. 
When the dialog with the user is completed, the tibio 
component publisher 501 , employs a standardized for- 
matting procedure to package all of the information and 
resources into a single convenient file. 
45 [0024] The tibio component gallery 503 provides a list 
of all tibio components that are available to the user. The 
tibio components listed in the tibio component gallery 
503 may have been locally published, may have been 
purchased from commercial tibio component vendors, 
50 may have been downloaded via the Internet, or acquired 
by other means. Regardless of how they were acquired; 
they will all be listed in the tibio component gallery. In 
the preferred embodiment, the tibio component gallery 
503 will provide additional features, which may include 
55 sorting tibio components based on user-defined prefer- 
ences, providing descriptive information about each ti- 
bio component, and direct Internet access to additional 
vendor information. The tibio components that appear 
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in the tibio component gallery 503 do not have to reside 
on the local machine. In addition, the tibio component 
gallery 503 may list tibio component tokens. 
[0025] Tibio component-tokens are tibio components 
where some of the functionality has been removed or 
disabled. In one sense, tibio component-tokens may be 
considered as an electronic brochure for a real tibio 
component, tibio component tokens provide several in- 
teresting possibilities: 1) they may be distributed at no 
charge for promotional purposes, 2) they may provide 
limited functionality or no functionality, and 3) they pro- 
vide a local stub that can point to the real tibio compo- 
nent, tibio component tokens are published exactly the 
same way that normal tibio components are created, 
with two small exceptions: 1 ) some of the resources may 
be removed or disabled, and 2) a token attribute is set. 
The token attribute is a means for all tools that access 
or use tjbio components to recognize that this particular 
tibio component is a token. A hyperlink to an Internet 
website may be included in a tibio component-token to 
assist users in getting additional information or in up- 
grading tibio component-tokens to "full-strength" tibio 
components. 

[0026] The primary user interface for the graphical so- 
lutions development system 500 is provided by the tibio 
component assembly tool 507, In the jargon of tibio com- 
ponent-based software, the term " tibio component as- 
sembly" refers to the composition or aggregation of tibio 
components into a.higher-level solution. The tibio com- 
ponent assembly too!;507 is therefore a graphical "drag- 
and-drop" editorthatis specif ically optimized to facilitate 
"tibio component .assembly". Figs. 6, 17A, and 22A il- 
lustrate screen shots' of tibio drawings in which various 
tibio components have been dropped. Besides offering 
the user a graphical drawing environment, the tibio com- 
ponent assembly tool provides an extended user inter- 
face that permits the user to build, load, run, and debug 
complex projects. 

[0027] During the design phase, sometimes referred 
to as "design capture", the designer has many opportu- 
nities to make errors. These can be as simple as forget- 
ting to use unique names for each tibio component in- 
stance (block) on the tibio drawing. To help the user 
avoid mistakes, especially new users, the graphical so- 
lutions development system includes a tibio framework 
504. In the preferred embodiments, a tibio framework is 
defined as a collection of rules and a rule engine that 
can detect rule violations. This is very analogous to the 
spell-checker in a word-processor. A spell-checker is 
comprised of a set of rule (i.e. the dictionary) and the 
spell-check engine. The "dictionary" provides rules re- 
garding spelling and hyphenation. The spell-check en- 
gine compares each word in a document to the words 
in the dictionary. Similarly one part of a tibio framework 
consists of a set of rules that are compiled by experts. 
The other part of the tibio framework is an applet that 
can apply the rules to the current tibio drawing and de- 
tect errors. 



[0028] The tibio component assembly tool also pro- 
vides- an interface to code-generation and other build 
tools 505. This facility permits the project or projects to 
be compiled, assembled, linked, built, or it can invoke 

s any other build process needed. (Each tibio component 
includes some embedded build information.) The out- 
files 506 which are the result of the build process can 
be directly loaded into appropriate target platforms, or 
may be manually loaded into target platforms. Data 

io viewer applets 508 provide a capability similar to an os- 
cilloscope and thus permit the user to visually inspect a 
project while it is "running". This capability facilitates 
both debugging and performance assessment. 

15 B. tibio components 

[0029] Tibio components are self-contained, deploy- 
able units of software or hardware functionality. After a 
tibio component is instantiated in a tibio drawing it is 

20 symbolically portrayed on the main computer display 
105 as either a line drawing or as an image (bitmap 
icon). (A tibio component instance is often referred to as 
a "block".) Fig. 8A illustrates one possible rendering of 
a tibio component-instance 700 (i.e. block), as it would 

25 appear in a tibio drawing on the display screen 105 of 
the main computer system* 100. The tibio component- 
instance illustrated in Fig. 8A comprises a body 701 and 
a collection of optional pins that are usually located 
around the periphery of the block's body. The. body 701 

30 of the block 700 merely serves to denote an entity. The 
body 701 may be rendered on the display screen .1:05 
using a fill color, a texture, or other fill means. The par- 
ticular "fill method" may vary from one block 700 to'the 
next. The "fill color" may be used to visually connote a 

35 particular block property (e.g. red may denote an error 
condition). The "fill color** or other visual attributes may 
be changed dynamically in response to various operat- 
ing or environmental "conditions". Blocks 700 usually 
support text fields 702 that can provide useful reference 

^0 information, like the instance name. 

[0030] A block may have four different kinds of pins, 
which are visually rendered using small, distinct icons. 
A data-input pin 703 represents a connection point 
where data, especially real-time data, may be applied 

45 as an input parameter to the functionality of the block. 
A data output pin 704 represents a connection point for 
data, especially real-time data, after it has been proc- 
essed by the block's algorithm or function. Wires repre- 
senting events or control information may be connected 

50 at the input event pin 705. Output events that result as 
a consequence of the block's normal processing oper- 
ation (e.g. execution of an algorithm) "appear" at the out- 
put event pin 706, where they may be connected via 
wires to other blocks. 

55 [0031] A block 700 may have any number (including 
zero) of each type of pin. The shape of the icon used to 
denote a pin is merely a visual cue for the user. In the 
preferred embodiment, any pin may be located at any 
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position along the periphery of the block 700. Pin colors 
as well as pin icons may be changed dynamically to vis- 
ually connote changes in properties or environmental 
"conditions". For example, the fill color of a pin may be 
changed to red to denote that no wire is connected 
(where a wire was expected). 

[0032] The tibio drawing of Fig. 8B illustrates the in- 
terconnection of three blocks using an abstraction re- 
ferred to as wires. Wire 803 visually depicts the fact that 
output data from the filter block 801 is to be used as 
input dataforthe processing operation performed by the 
gain block 802. In a similar manner, wire 805 illustrates 
that data events from the slider control are "fed" to the 
input event pin of the gain block 802. The slider control 
804 is activated by using a pointing device 1 06 to move 
the slider "thumb". Movement of the slider thumb gen- 
erates output events that provide thumb position infor- 
mation. Note that the software that implements the slider 
control may be executing on the main computer system 
100, while the signal processing operations performed 
by the filter 801 and gain 802 blocks may be executing 
on a secondary processing system. The important point 
here is that wires may span blocks associated with di- 
verse physical hardware. The label 806 is an annotation 
tibio component. Annotation tibio components are a 
special class of tibio components that do not contribute 
code to a project. Annotation tibio components are used 
to add descriptive information to a tibio drawing. Anno- 
tation tibio components include lines, arrows, textboxes, 
labels, icons, title boxes, etc. 

[0033] Each tibio component includes a set of prop- 
erties. Fig. 8C provides a table of example properties 
for a simple low pass filter tibio component. Most of 
these properties are defined when the tibio component 
is created. Some properties are used only at design- 
time, some are used only at build-time, and some are 
used only at run-time. The tibio component creator de- 
termines what properties will be included, whether they 
can be modified, and when they are accessible. 
[0034] In addition to a set of properties, a tibio com- 
ponent may include many other objects or kinds of in- 
formation. The tibio drawing of Fig. 8D shows some of 
the possibilities, tibio component properties 901 were 
described earlier. Vendor information 902 may include 
contacts, technical support information, promotional in- 
formation for other tibio component- related offerings, le- 
gal notices, etc. Source code files 903 and object code 
files 904 may also be included. For the protection of the 
vendor's intellectual property, the tibio component may 
be distributed without the inclusion of any source code 
files. Utilities 905 may include other tibio components, 
test applications, specialized compilers, or any other 
utility that the tibio component creator wishes to include. 
Help files 906 may include hypertext document files, text 
files, troubleshooting guides, application notes, etc. 
Configuration information 907 refers mainly to scripts. 
Scripts are brief code modules that can be executed by 
the GSDS to assist the GSDS in properly using and con- 



figuring each tibio component instance in each individ- 
ual environmental context. Configuration information 
may also include makefile information, memory require- 
ments, data format information, operating system pref- 
5 erences, etc. If the tibio component deals with a non- 
standard (or proprietary) type of data, then specialized 
data viewers 908 may be included inside the tibio com- 
ponent. Many other objects may also be included in a 
tibio component. 

10 

C. Tibio drawings 

[0035] Tibio components are the "building blocks" that 
are used to construct a solution to a problem. The use 
15 of a "block diagram" drawing paradigm greatly enhanc- 
es the user's ability to understand the high-level opera- 
tion of a tibio drawing. Many other formats, both graph- 
ical and non-graphical, are possible. Indeed, expanding 
lists of properties such as Fig.8C could take the place 
of the graphical representation of Fig.8A where the ex- 
panded list would include input and output connections 
by references to other lists, and so forth. 
[0036] The preferred embodiment graphical solutions 
development systems distinctly render tibio drawings 
featuring two different kinds of information, data-flow in- 
formation and control information; these are called tibio 
drawings. The distinction between data-flow and con- 
trol-flow may be visually represented using wires of one 
color for data-flow, and a different color for control-flow. 
Fig. 9 presents a simple, but complete, functional tibio 
drawing. In Fig. 9 data-flow information (i.e. data wires 
1 004,1 005) are rendered using solid lines. And the con- 
trol-flow in Fig. 9 is depicted using dotted lines for control 
wires 1 006, 1 007. Wires shown on the display screen do 
not connote electrical connections, but rather illustrate 
the flow of both data and control information. 
[0037] In Fig. 9 the sinewave generator 1001 repre- 
sents a code module that, when executed, mathemati- 
cally computes discrete samples of a sinusoidal signal. 
The numerical data for each sample generated by the 
sinewave generator 1001 is used as input data for the 
filter algorithm 1002. Because this "flow of information" 
from one algorithm to the next is perfectly analogous to 
analog signal processing where the output of one ana- 
log processing circuit (or "block") is connected via a wire 
to the input of the next analog processing circuit. For 
this reason, in Fig. 9 it is natural to depict the flow of 
data from the sinewave generator 1 001 to the low-pass 
filter 1002 symbolically as a wire 1004. Using this con- 
vention the computed data out of the low-pass filter 1 002 
is "connected" to the digital-to-analog converter (DAC) 
1 003 using another wire 1 005. Wires 1 004 and 1 005 vis- 
ually connote a data path (i.e. data-flow). In Fig. 9 the 
frequency property of the sinewave generator 1 001 may 
be modified by the user, while the system is in operation , 
via the frequency slider control 1 008. Movement of slid- 
er thumb generates slider events which are forwarded 
to the sinewave generator 1 001 via wire 1 006. The low- 
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pass filter 1 002 is configured in a similar manner so that 
the cut-off frequency of the filter may be modified (at run- 
time by the user) by moving the thumb of the "Cutoff 
Frequency" slider 1009. Control events from the Cutoff 
Frequency slider are connected to the low-pass filter 
1002. Event wires 1006, 1007 depict control-flow infor- 
mation. Distinctly showing the data-flow and control- 
flow information is an improvement that helps the user 
comprehend complex processing operations using very 
simple schematic representations. The instance name 
,, SLIDER02" 1010 is an optional label. The platform 
block 1011 , represents the actual hardware where this 
tibio drawing will execute. The platform block includes 
an operating kernel and a variety of build information. 
[0038] Data-flow information pertains to data that 
must , be processed such that various operations are 
completed in compliance with real-time deadlines (e.g. 
filtering of an audio data stream) where violations of the 
real-time deadlines may cause problems or failures (e. 
g. failure to maintain real-time filtering of an audio 
stream can cause pops, clicks, or dropouts). 
[0039] Fig. 1 0A provides an illustration of a very sim- 
ple real-time processing scenario. Data from some real- 
time process (like the audio signal inside a television 
set) is suitably "fed" to two input data buffers 1101 , 1102. 
In this example each data buffer might be comprised of 
sufficient memory to store 64 data samples. Normally 
after Buffer A 1 1 01 is filled with real-time data, processor 
1 1 03 commences the execution of a desired processing 
algorithm (e.g. filtering out noise). Following the 
processing of the. data in Buffer A, this resulting data is 
forwarded to an output device 1104. While the data in 
Buffer A is being processed, the input data stream is 
"fed" to Buffer B. After Buffer B is filled with real-time 
data, the processor will commence processing of the da- 
ta in Buffer B. Processing continues in alternating fash- 
ion with each buffer being replenished with new data 
samples while the data in the other buffer is processed. 
Successful processing is predicated, as shown in Fig. 
10B, on the fact that the processor is sufficiently fast 
such that it can complete the processing of a single buff- 
er of data before the next data buffer is full. The term 
"Real-time deadline" means that there exists a point in 
time where processing of one buffer must be completed 
so that processing of a new buffer can begin. Fig. 1 0B 
shows a case where the processing time concludes well 
before the Real-time deadline. Alternatively, Fig. 10C 
shows a case where the processing time exceeds the 
real-time deadline. The result here would likely be man- 
ifest as some audible impairment. 
[0040] Control information pertains to "asynchro- 
nous" control operations like changing a volume control 
setting. Control operations are not time critical, and 
hence real-time deadlines are not imposed. The graph- 
ical solutions development system has the ability to de- 
fine and, in fact, process these two distinctly different 
types of "information" in completely different ways. 
[0041] The preferred embodiments have devised a 
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way so that neither the tibio component that creates the 
event, nor the tibio component that will receive the event 
. has to know how the "event information" is being trans- 
mitted. Indeed, both the tibio framework and the tibio 

5 components have the capability to adapt and automat- 
ically implement compatible encoding /decoding proto- 
cols. To accomplish this, code is added to the project. 
This code may be generated by the tibio framework or 
by the tibio components. The software that does the en- 

10 coding is called a PROXY. The code that does the de- 
coding is called a STUB. 

[0042] In prior art, event wires have been used to il- 
lustrate the routing of event information. In contrast, the 
preferred embodiments the method used to implement 

15 the communication channel does not have to be defined 
or standardized when the tibio components are created, 
but rather they can be defined when the tibio compo- 
nents are "assembled" into a solution. So our event 
wires do not represent a fixed event mechanism, they 

20 are more like chameleons. 

[0043] In a tibio drawing, the control flow scenario 
consists of the elements listed below. These are illus- 
trated in Figure 8B. 

25 - Source Block 804 - block that generates an output 
event 

Source Pin 824 - output event pin on the source 
block that generates the output event ■ - 
Destination Block 802 - block that receives the input 

30 event 

Destination Pin 822 - input event pin on the desti- 
' nation block receiving the input event , ^ 
Control wire 805 - channel on which the controlHn- 
formation flows from an output event pin to an input 

35 event, pin 

Proxy code - code generated for the source pin to 
. map the control information from the source block 
to the wire and/or destination pin on the destination 
block 

*o - Stub code - code generated for the destination pin 
to map the control information from the source pin 
and/or wire to the destination pin on the destination 
block. 

45 [0044] In Figure 8B, the Volume control tibio compo- 
nent 804 generates output events whenever the slider 
thumb is moved. The event wire 805, represents a com- 
munication channel (or protocol) that delivers the output 
events from the Volume control to the Gain control tibio 

so component 802. The Stub code and the Proxy code are 
not usually supplied by tibio components, but rather are 
provided by a tibio framework. (The cal louts in Figure 
8B make it look like the Proxy and Stub are either part 
of a pin or part of a tibio component. They could be inside 

55 of the tibio component orthey may not be. They are usu- 
ally associated with the respective pins, so this is more 
of a conceptual convenience.) 

[0045] Figure 25A provides a simple illustration where 
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a volume control "slider component" sends events to a 
gain control component via a shared memory. For this 
protocol, the slider can send output events by calling the 
(proxy) ControlObjectX function shown in Fig. 25B. In 
this case events are represented as integers. Input 
events are received by calls to the (stub) stubControlOb- 
jectX function given in Fig. 25C. 

[0046] Figure 25D implements a completely different 
physical connection to pass events from the volume 
control slider component to the gain control component. 
In this case, the events are sent from a personal com- 
puter to a telephony device via a universal serial bus 
(USB) connection. 

[0047] The code for the proxy and the stub that send 
and receive events using the USB connection are given 
in Figures 25 E and 25 F, respectively. Note that, just as 
in the previous description, the proxy is provided by a 
call to the ControlObjectX function, and the stub is pro- 
vided by calls to the stubControlObject function. Note 
that the proxy and stub have the same calling conven- 
tions (same function names and same parameters are 
passed) The slider component and the gain component 
have no control over how the events are being passed. 
[0048] This example can be expanded to cover a wide 
variety of situations that include different physical loca- 
tions, different electrical (or other) connections, different 
protocols, etc. The source and destination blocks can 
be located anywhere in a GSDS (tibio) drawing; in fact, 
the source and/or destination block(s) could be external 
to the GSDS drawing, such as applications not repre- 
sented in the GSDS drawing. Examples include, but are 
not limited to the following: 

Source and destination blocks can be executing in 
the same task, or different tasks 
Source and destination blocks can be executing in 
the same process, or different processes 
Source and destination blocks can be executing on 
the same processor, or different processors 
Source and destination blocks can be executing on 
the same platform, or different platforms 

[0049] A proxy is the interface between an output 
event pin and a wire. A stub is an interface between a 
wire and an input event pin. The source and destination 
pins define the format of the information at the pin or the 
interface between the block and the wire. The definition 
of the interfaces can take on any form that can be de- 
scribed by an interface definition file. Interface examples 
include, but are not limited to, the following: 

Global variable 
C function call 

Collection of C function calls 

C++ function call 

Collection of C++ function calls 

COM interface 

Assembly calling convention 



Data page pointer calling convention 

[0050] In the GSDS the interface definition may be de- 
fined by a block when it is instantiated, or it may be left 
5 undefined, relying on the tibio framework to assign an 
optimum interface implementation. Examples include, 
but are not limited to, the following: 

Source block output event pin defines output event 
10 interface 

Source block output event pin adapts output event 
interface 

Destination block input event pin defines input 
event interface 

15 - Destination block input event pin adapts input event 
interface 

[0051] The normal combinations are: 

20 - Source block defined output event interface is tied 
to a destination block adapting input event inter- 
face, in this case the stub code automatically 
adapts to the proxy code. 

Source block defined output event interface is tied 
25 to a destination block defined input event interface. 
In this case a suitable translation (or mapping) is 
generated either in the proxy or the stub or both to 
match the information definitions. 
Source block adapted output event interface tied to 
30 a destination block adapting input event interface. 
Here the tibio framework specified the optimum 
mapping. The proxy and stub default to the best ob- 
tained solution. 

Source block adapted output event tied to a desti- 
35 nation block define input even - the proxy code 

adapts to the stub code 

[0052] The proxy and stub code may also be a func- 
tion of the properties of the wire interconnecting them. 
40 The wire represents a channel of control information 
flow. The properties of this channel (i.e. wire) are a func- 
tion of many items including, but not limited to, the fol- 
lowing: 

45 - Relative physical locations of the source block and 

the control block 

Platform characteristics 

Processor characteristics 

RTOS currently loaded 
50 - Communication mechanism (parallel port, shared 

memory, etc.) 

Operating system support 

[0053] Although there are thousands of possible 
55 event passing mechanisms (or channels) the code in- 
side a block is always the same. The application code 
in each block simply makes that same API call no matter 
what event-passing scheme is in effect. The entire 
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proxy/stub mechanism can be later refined with out any 
changes to the application code. This makes it possible 
to create tibio components that remain versatile and 
compatible in the face of many possible event-passing 
conventions. 5 
[0054] A block may define any number of control in- 
terfaces by defining source (output events) and destina- 
tion (input events) pins. Each pin can have a different . 
format for the control information. 

10 

D. Types of tibio components 

[0055] Several different types of tibio components can 
be used in a tibio drawing. The most obvious tibio com- 
ponents are software tibio components. Software tibio 15 
components are tibio components that ultimately pro- 
duce instructions for one or more processors. Typical 
tibio components include software that is designed to 
perform a pre-defined task (e.g. a sinewave signal 
source). Other types of tibio components include hard- 20 
ware components, platform components, framework 
components, annotation components, and intrinsic 
components. 

[0056] Platform components are tibio components 
that contain information about the target hardware 25 
where the project's executable code will be "run". 
[0057] In some cases, the operating system or kernel 
may be represented via a tibio component. In this in- 
stance the operating system component can have user- 
accessible properties; it may or may not expose any 30 
pins. 

[0058] Hardware components may also be used to 
represent hardware rather than software functions, for 
example a digital-to-analog converter, or a data-access- 
arrangement (DAA) for a modem. While these hardware 35 
components are implemented using electronic hard- 
ware (e.g. resistors, capacitors, integrated circuits, 
transformers, etc.) rather than being implemented in 
software, they usually require software to appropriately 
configure them for proper operation in accordance with 40 
their property settings. A codec, for example, may need 
a special software driver to configure sample rates, anti- 
aliasing filters, channel selection, data format, etc. 
[0059] Fig. 11 provides an example of a hardware 
component: the telephone-line interface 1300 (com- . 45 
monly referred to as a DAA, an abbreviation for "direct 
access arrangement"). This interface 1300 is truly a 
hardware component because it comprises several 
hardware devices like a transformer 1301 , a ring-detec- 
tor 1302, and a relay 1303. The DAA accepts one input 50 
event 1306 that is a command to put the telephone line 
into the "Offhook" state (equivalent to picking up the 
handset on a common telephone device). The DAA also 
produces one output event 1 307. The output event 1 307 
is generated each time the central telephone office 55 
sends a RING signal. A DAA 1300 is commonly used 
as an interface between the telephone line and the cir- 
cuitry of the modem. In such an application, the modem 



software is responsible for generating appropriate out- 
put events to the DAA, and for processing incoming 
events from the DAA. The ability to represent a hard- 
ware component in a GSDS drawing provides a power- 
ful improvement, 

[0060] Some hardware components may represent 
programmable logic that can implement suitable algo- 
rithms, state machines, etc. The GSDS may provide 
software optimization modules that help optimize the 
partitioning of processing tasks between hardware (ex- 
ecuted via hardware logic) and software (executed on 
a microprocessor). The illustration of Fig. 12 gives an 
example of how a programmable logic device 1405 
(PLD) can be used to implement a data-processing tibio 
component. This tibio component would be represented 
in a GSDS drawing as a simple block having two data 
pins: Data In and Data Out. In operation the program- 
mable logic device 1405 would be programmed (when- 
ever required) via an interface 1406 to the microproces- 
sor 1403. The processor 1403 might access desired al- 
gorithms or programming instructions from either its res- 
ident memory devices 1401 or from an external source 
via a general-purpose communication channel 1404. 
[0061] Framework components are tibio components 
that supply rules and/or rule-checking engines that sup- 
port verification of proper tibio component usage which 
may include wiring, tibio component property. settings, 
data formats, event-passing protocols, etc. ~ 
[0062] For clarity, a tibio drawing on the main compu- 
ter display may need to be annotated with textboxes, 
dotted lines, labels, etc. These are all visual annotation 
tibio components that contribute no software code. 
However a dotted box around a group of tibio compo- 
nents may represent a specific group property (e.g. a 
specific task with properties like priority). In this in- 
stance, although the dotted box does not directly add 
any code to the project, it may denote a certain condition 
that requires code for satisfaction. Fig. 13 provides a 
simple tibio drawing featuring several annotation com- 
ponents. The textbox 1501 enables the user to add ex- 
planatory text to a tibio drawing. Textboxes are resiza- 
ble, and both the fill color and the line color can be user 
selected. The rectangle 1502 can be used to denote 
items in the tibio drawing that have some common char- 
acteristic. Lines 1503 can be used to create line draw- 
ing. Text labels 1 504 can also be added to provide clar- 
ity. These are just a few of the possible annotation com- 
ponents; others include circles, block arrows, callouts, 
dotted lines, and bitmapped icons. Because annotation 
components represent the special case of being totally 
passive in every way, they do not have to be stored in 
the same file format as other tibio components. Also 
they may be accessed from a convenient toolbar rather 
than from the tibio component gallery. 
[0063] Intrinsic components are those tibio compo- 
nents that are available from the graphical solutions de- 
velopment system. These are only available while the 
GSDS is running. These are very handy for debugging 
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purposes. Intrinsic components always run on the main 
computer system 100. They do no belong to a project 
and they do not contribute code to a project. 
[0064] User-defined components are representatives 
of another type of tibio component. These are " tibio 
component shells" that have little or no inherent code. 
User-defined components provide editing capabilities 
(like text editing) so that software code (e.g. C source 
code) can be entered directly by the user, pins can be 
added, and properties can be defined. These tibio com- 
ponents are similar in every way to other GSDS compo- 
nents, but they permit a user to completely define their 
functionality (via user-entered code rather than graphi- 
cal components). After the user finishes writing and de- 
bugging the code in a user-defined component, the us- 
er-defined component will be graphically represented in 
a tibio drawing as a block similar to any other block. 
[0065] One possible user interface 1 600 for the User- 
defined component is given in Fig. 14A. This user inter- 
face 1 600 is comprised of a menubar 1 601 , a treeview 
1602 of project folders, an edit window 1 603, and a sta- 
tus window 1 604. Because the user has configured this 
user-defined component to execute in the "Dsp Process" 
project, the treeview window 1 602 is currently displaying 
the contents of the "DspProcess" project folder 1607. 
Code files for this particular tibio component instance 
are created in the appropriate project folders. The head- 
er file is created in the "Include" folder 1 605, and the C 
source file is created in the "Source" folder 1606. As the 
full tibio drawing is composed, by adding additional tibio 
components, additional header and source code files 
will be copied into these same project folders. 
[0066] The edit window 1603 provides a text-editing 
capability (including text entry) that permits the user to 
write any source code needed to implement the desired 
function. In some implementations the user interface 
1600 may employ an external editor of choice. 
[0067] The status window 1604 displays helpful sta- 
tus information during compile and debugging opera- 
tions. 

[0068] Fig. 14B shows a GSDS drawing of a simple 
"program" that includes a user defined component 
1650. This block has an instance name of "Ublkl" has 
been employed to realize a proprietary modulation al- 
gorithm. 

[0069] Note that the user-defined code block may also 
be used to create user-defined algorithms for a pro- 
grammable logic device, like the example in Fig. 12. In 
such a case, the "code" might be written in a different 
language, and also might be compiled with a special 
"PLD" compiler. 

[0070] Tibio components may also be used to repre- 
sent the combined functionality of an aggregate com- 
posed of both hardware and software. An example 
might be a modem component. 



E. Property Dialogs 

[0071] After the user creates a tibio drawing, but be- 
fore it runs for the first time, the user usually needs to 

5 configure the property settings for each tibio component 
on the tibio drawing. As seen in Fig. 8C, each tibio com- 
ponent has a number of property settings that are pro- 
vided to specifically define how the tibio component 
should operate. 

10 [0072] User access to property settings may be pre- 
sented to the user in several different ways including list- 
boxes (very similar to Fig. 8C), icon-based graphical us- 
er interfaces, dedicated property dialog windows, and 
via "wizards" that prompt the user for performance-re- 

15 lated information and then process the user inputs to 
determine actual property settings. A typical property di- 
alog for a finite-impulse response filter (i.e. FIR filter) is 
given in Fig. 15. Note that this property dialog window 
is composed of drop-down lists, labels, edit boxes, and 

20 buttons. There is also a graphical icon to generically por- 
tray the filter characteristic. From the user-supplied in- 
formation (entered in this window) several different ac- 
tivities can be completed automatically: 1) the number 
of filter sections can be computed, 2) the coefficients for 

25 the filter can be computed, 3) the appropriate code mod- 
ules can be selected, 4) the code can be modified by 
insertion of the proper coefficient values, etc. This ex- 
ample clearly exemplifies one of the major benefits of 
the graphical solutions development system and the use 

30 of intelligent tibio components: The user is able to ac- 
cess optimized functionality of a FIR filter without having 
to 1) understand how a FIR filter works, 2) write any 
code, 3) determine the number of filter sections needed 
to achieve desired performance, or 4) calculate the nec- 

35 essary filter coefficients. 

[0073] Tibio component property values, set by the 
user, are frequently used to determine which software 
code modules should be contributed to a solutions 
project. Figures 1 6 A, 1 6B, and 1 6C provides a simplified 

40 example of how a tibio component may contribute dif- 
ferent code modules to a solutions project depending 
on its property settings. As seen in Fig. 16A, a property 
dialog for a waveform-generator tibio component may 
offer the user a property dialog where the user can se- 

45 lect the desired output waveform. In this example the 
waveform option-box indicates that the user has select- 
ed the "Triangle" waveform. Fig. 1 6B gives a table show- 
ing some of the resources that are encapsulated in the 
waveform generator tibio component. The person who 

50 created this tibio component knew that if a user wished 
to achieve the "Triangle" waveform, that this tibio com- 
ponent should copy the "triangle files" (triangle.h, trian- 
gle.c, and triangle.obj) into the project. To accomplish 
this the person who created the tibio component would 

55 include an "OnProperty" script similar to the one shown 
in Fig. 16C. The OnProperty script permits the tibio com- 
ponent creator to deliver a measure of his "integration 
knowledge", valuable insight about how the tibio com- 
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ponent can be integrated into a project to implement a 
useful solution. 

[0074] The OnProperty script implements five essen- 
tial functions: 1) Whenever the OnProperty script runs, 
it generates the dialog window that is shown in Fig. 16A. 
2) When the OnProperty dialog window closes, deter- 
mine if it was closed with an "OK" (button click) result or 
with a "CANCEL" (button click) result. 3) If the dialog 
window was. terminated via the OK button, then deter- 
mine the user-selected waveform. 4) Based on which 
waveform was selected, copy appropriate software 
modules to the project. 5) If the dialog was closed via 
the CANCEL button, then do nothing. 
[0075] All of the logical flow of the OnProperty script 
represents "intelligence" that the tibio component author 
embeds in the tibio component when it is created. If two 
different experts decide to separately publish a tibio 
component offering the same functionality, the expert 
who better understands how the tibio component can be 
used and how the code may need to be modified (or 
"tweaked") for various operating situations will enjoy a 
competitive advantage. 

[0076] F. Deriving the Software Code for a Project 
from a Tibio Drawing Before any solutions project can 
be "built" (e.g. compiled, etc.) and "run" there are sev- 
eral activities that must be completed^ .1 ) all necessary 
source-code modules must be deposited into appropri- 
ate file folders, 2) all necessary "include" files must be 
copied into appropriate file folders, 3) all header files 
must be copied to appropriate file folders, etc. In the 
case of a GSDS project there are additional complexi- 
ties. First a'^ain" source file (e.g. main.c) must be gen- 
erated. While the code modules for each tibio compo- 
nent can be composed when the tibio component is cre- 
ated, the "main" source file, which represents how the 
various tibio components are interconnected, cannot be 
written (or generated) until a tibio drawing has been 
completed. One of the main goals of the GSDS is to as- 
sist new users in accessing powerful technology that 
has heretofore been the private domain of a relatively 
small group of experts. For this reason, the GSDS im- 
plements a strategy that can "inspect" a tibio drawing 
and automatically generate the appropriate "main" 
source file. The next few paragraphs explain how the 
GSDS extracts and processes information from a tibio 
drawing to generate a complete project that matches the 
user's expectations. 

[0077] The screen shot of Fig. 1 7A shows a function- 
ally complete GSDS drawing as it appears in the GSDS 
development environment. This tibio drawing shows two 
instances of a sine-wave component 1701 ,1 702. These 
blocks have instance names "SIN1 M and "SIN2" respec- 
tively. The outputs of the two sine-wave blocks are con- 
nected to an arithmetic-logic unit (ALU) block 1 703. The 
instance name (or blockname) of this block is "ALU 1 
The ALU block generates an output signal that is math- 
ematically computed from the two input signals based 
on an "operation" property that is set by the user. The 



operation property is confined to one. of four possible 
math operations: add, subtract, multiply, or divide. In this 
particular tibio drawing, the ALU block 1703 is config- 
ured for addition, and a label is provided to indicate 

5 which operation is currently selected. Here the label 
shows a plus sign (+) to indicate addition. The output 
signal from the ALU 1703 is connected to a digital-to- 
analog converter (DAC) block 1704. A slider control 
1705 is connected to the "Frequency-Input-Event" pin 

10 on sine-wave generator 1 702. (Note: To avoid clutter, 
there are no labels on any of the pins. However, anytime 
that the screen cursor is positioned near a pin on any 
block, a label (often referred to as a "tool-tip") appears 
to provide the pin-name and datatype.) When this tibio 

15 drawing is "run", the slider control 1 705 permits the user 
to vary the frequency of the SIN2 sine-wave generator 
1702. The platform block 1706 is labeled "C3xDSK". 
The platform block provides information about the actual 
hardware, which in this case is a Texas Instruments 

20 TMS320C3X DSP Starter Kit. 

[0078] After constructing this tibio drawing, the user 
has an opportunity to set the properties of each block 
on the tibio drawing. User access to property settings is 
via a property dialog window. There are several ways to 

25 invoke a block's dialog window, including "double-click- 
ing" on a block with the pointing device. The property 
dialog window for the sine-wave block is shown in Fig. 
1 7B. The "Name" field is an editbox where the user can 
enter the desired instance name. In any given project, 

30 all instance names must be unique. If two or more blocks 
are given the same name, then the tibio framework'will 
detect a name "clash" and warn the user. The GSDS 
provides a user selectable feature referred to as "auto- 
naming" that will automatically generate unique names 

35 as each block is added to a tibio drawing. The user has 
the option to over-ride the automatically assigned name. 
The "Label" field is an optional property that will add a 
text label to a tibio component. (In the ALU block 1 703, 
the label field is used to exhibit the arithmetic operator.) 

40 The "Fout" field sets the default sine-wave frequency. 
At runtime, the sine-wave block will generate sinusoidal 
data at the default frequency until it receives a frequen- 
cy-change event at the "Frequency-Input-Event" pin. 
The "Vout" field sets the default value of the peak am- 

45 plitude of the computed sinusoidal data. Because this 
tibio drawing 1 700 uses two sine-wave generators, the 
values for each on these blocks must be set individually. 
[0079] The property dialog window for the ALU block 
is given in Fig. 17C. Here the desired "Operation" is us- 

50 er-selectable via a "drop-down" list control. 

[0080] Similarly, a property dialog window for the dig- 
ital-to-analog converter is provided in Fig. 17D. For this 
particular DAC implementation, the data sampling rate 
is user selectable from this dialog window. In many cas- 

55 es, the data sampling rate will be defined using alternate 
methods. 

[0081 ] The platform block 1 706 provides the property 
dialog window shown in Fig. 17E. This particular plat- 
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form includes a modular kernel, where individual kernel- 
modules are user selected as shown in the figure. The 
ability to custom tailor the operating kernel permits the 
user to minimize memory usage. 
[0082] The property dialog window shown in Fig. 1 7F 
is for the slider control 1705. Movement of the slider 
thumb from one extreme to the other (i.e. far left to far 
right) will produce events with values varying from a min- 
imum of 150 to a maximum of 3000. The actual event 
values that are generated will be directly proportional to 
the position of the thumb. The slider control only gener- 
ates output events when the slider thumb is moved. The 
"Orientation" field conf igu red the visual orientation of the 
slider block icon on the display screen. The only two op- 
tions are horizontal and vertical. 

[0083] Inside of each tibio component there are many 
files and/or resources. Among these resources are 
script files that are used by the GSDS to permit each 
tibio component to react to the GSDS and its environ- 
ment in its own unique way. In the example tibio drawing 
1700, most of the tibio components include three differ- 
ent scripts: OnProperty, OnDeposit, and OnAssemble. 
Each of these scripts is executed by the GSDS at differ- 
ent times in the design process. The OnProperty script 
is executed whenever the user requests the property di- 
alog window. Whenever the "build" process is initiated, 
two activities must be accomplished. First, the wire in- 
terconnections must be analyzed to determine how the 
data should pass from one block to the next, and how 
events should be passed from one block to the next. 
Second, the source code for the "main" module must be 
generated. During the next phase of the build process, 
the block list is again traversed and the OnDeposit 
scripts for each block are executed. OnDeposit scripts 
are employed to copy files and resources from inside 
the block to the appropriate project folders. 
[0084] All of the information shown on the tibio draw- 
ing 1 700 is maintained by the GSDS in a comprehensive 
tibio drawing object array. The script language, which is 
similar to Microsoft's Visual Basic for Applications 
(VBA), has been extended with a powerful set of APIs 
(application -programmer interfaces) that permit scripts 
to both query and modify objects in the tibio drawing ob- 
ject array. The APIs comprise a set of basic functions 
that can count the number of elements in a' collection, 
can obtain object names based or pointers (and vice 
versa), can read or modify property settings, and other 
similar functions. These APIs in tibio component-borne 
scripts provide programming power. 
[0085] The OnProperty script for the sine-wave com- 
ponent is given in Fig.17G. This script had three sec- 
tions that are of note. The first section 2301 is the code 
that defines exactly what the dialog window will look like. 
This specifies the size and layout of the dialog window, 
all labels, all edit-boxes, and all pictures and buttons. 
[0086] The second section 2302 of interest retrieves 
the previously set property values for the block and up- 
dates the dialog controls in the property dialog window. 



The first time that the property dialog window is present- 
ed, the user will have had no opportunity to make any 
property modifications. In this case, this section of code 
detects that no properties have been set, and default 

5 values for all properties are automatically generated. 
[0087] The third section of interest 2303 determines 
what happens when the dialog window is dismissed. If 
it is closed via the "OK" button, then the block properties, 
which are maintained by the GSDS, are updated with 

10 the values that have been entered in the property win- 
dow. If the property window is closed via the "Cancel" 
button, then the script makes no changes to the block's 
current property values. 

[0088] Every block in the tibio drawing 1700 has a 

15 similar OnProperty script. 

[0089] The OnAssemble script 2500 for the sine-wave 
generator is shown in Fig. 171. Code 2501 is retrieving 
pointers to the current block, current project, and current 
workspace. Code 2502 traverses the object array to de- 

20 termine the name of the wire attached to the sine-wave 
generator's output pin. The wire name is used as a pa- 
rameter in the "main" code file. Code 2503 queries to 
getthe default property values for both signal frequency 
and signal amplitude. These will be used to initialize var- 

25 iables in the "main" source file. Code 2504 determines 
the pin names for the event pins and concatenates the 
pin names with the blockname to generate unique var- 
iable names. Code 2505 builds declaration strings that 
will be pasted into the declaration section of the "main" 

30 source file. Similarly code 2506 builds strings that, when 
pasted into the "main" source file will be the actual func- 
tion calls to the two functions that, by tibio framework 
convention, every tibio component must export. These 
are an IN IT function to perform initialization, and a 

35 PROCESS function that is called at the sampling rate. 
The PROCESS function provides all mathematical or 
logical operations that the block is to apply to each data 
sample. 

[0090] A similar sequence of OnAssemble operations 

40 is repeated for each block in a project. This represents 
a rather diverse data gathering operation. It would be 
very time consuming and inefficient to iterate through all 
the blocks to getthe include-file information, then iterate 
through all of them again to getthe wire variable names, 

45 then iterate again for block declarations, etc. A further 
difficulty woufd occur when a tibio component is instan- 
tiated more than once in a tibio drawing (like two sine- 
wave generators in tibio drawing 1700). This would pro- 
duce duplicate include statements, multiple copies of re- 

50 sources, as well as duplicate object code. The GSDS 
employs a novel concept called a fragment map. A frag- 
ment map is a temporary collection of data fragments. 
Each data fragment can be a line of code that needs to 
be included in the "main" source file. Fragments are or- 

55- ganized into appropriate groups such as "Include", "I nit", 
"Declare", etc. The entire fragment map can be gener- 
ated in a single traversal of the block list. After the frag- 
ment map is generated, it is a rather simple matter to 
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copy the fragments into the "main" source file in the 
proper order. Duplicates are easily filtered out during 
this main-file synthesis operation. Code section 2507 is 
an example of several code fragments being added to 
the fragment map. 5 
[0091] Again, nearly every block will have a similar 
OnAssemble script. 

[0092] Fig. 17H provides the OnDeposit script 2400 
for the sine-wave generator. Code section 2401 queries 
to get pointers to the current block, the current project, to 
and the current workspace. Code section 2402 illus- 
trates how resources within the block are copied into ap- 
propriate project folders. 

[0093] After all of the scripts have been run and the 
fragment map is completed, the GSDS copies and filters 
the fragments into the main source file. Fig. 17J provides 
a listing of the main source file 2600. In this instance, 
the main source file is named "DspMain.c". With the ex- 
ception of the comments, this file was completely syn- 
thesized automatically by the GSDS. Subsequent 
GSDS operations would include compiling and linking. 

G. tibio component Gallery 

[0094] The development system features a tibio com- 
ponent gallery that provides a list of all tibio components 
that are available to the user. These tibio components 
may reside on the main computer system 100, or they 
may reside on remote systems (accessed via a local-, 
area network or the Internet). The tibio component gal- 
lery may present a combined listing of both local and 
remote tibio components. The tibio component gallery 
offers "filtering" options so that only tibio components 
with certain features are presented in the gallery. (For 
example, only show tibio components that are compat- 
ible with the Texas Instruments TMS320C5410 digital 
signal processor.) Filtering is a convenience that reduc- 
es clutter and enhances productivity. Fig. 18 presents 
one possible rendering of a tibio component gallery. 
Note that the tibio component gallery could be repre- 
sented using a set of icons rather than a list of text en- 
tries. The GSDS component gallery can automatically 
adapt to the tibio drawing. One example is that once a 
platform component is added to a tibio drawing, the tibio 
component gallery can automatically filter the available 
tibio components, and then show only the tibio compo- 
nents that are compatible with the particular hardware 
on which they will be executed. The user can configure 
tibio component gallery options to determine which fil- 
tering operations are desired. 

H. Tibio frameworks 

[0095] Digital signal processing algorithms and digital 
signal processors are very complex. There is a limited 
cadre of experts who are able to produce effective digital 
signal processing solutions in a timely manner. The 
"journey" that a novice programmer must endure to 



reach even a minimum level of achievement and satis- 
faction is long, slow, and tedious. The graphical solu- 
tions development system attempts to minimize the dif- 
ficulty that a digital signal-processing neophyte experi- 
ences. The ideal, but impractical, solution would be to 
have a digital signal processing expert silling right be- 
side the user to warn and explain things at each stum- 
bling point. The development system provides an alter- 
native, referred to here as atibio framework. In practical 
terms, the concept of a tibio framework is actually better 
than a resident expert in many ways. It is not subject to 
human error, it is tireless, and it is not intimidating. The 
tibio framework is comprised of a set of rules and a rule 
engine that is implemented in software in the graphical 
solutions development system application. The tibio 
framework rules are composed by a team of experts 
who understand the many subtle issues, the tradeoffs, 
and the quirks involved in implementing digital signal 
processing solutions. Each time that the user changes 
anything on the screen (e.g. adds a tibio component, 
moves a wire, changes a property) the rule engine ex- 
ecutes the appropriate rules and provides user feed- 
back. A simple example of a rule violation is where a 
wire is drawn from a pin that sends out 16-bit data to a 
pin that expects 8-bit data coming in. Depending on user 
preferences, main computer system speed, and other 
factors, the rule engine may be programmed to run after 
every tibio drawing change, or only after specific events. 
[0096] The data that comprise the rules and the rule 
engine of a tibio framework may be physically distinct, 
or they may be "hard-coded" into an integrated imple- 
mentation. A hard-coded implementation makes it more 
difficult to change rules, but this disadvantage is offset 
by enhanced execution speed. 

[0097] A complete tibio framework example is provid- 
ed in Fig. 1 9D. This tibio framework script code sequen- 
tially calls subroutines that verify rules for the work- 
space, the project, the blocks, and the wires . This simple 
example is somewhat deceptive. If a more robust tibio 
framework were invoked to "examine" a non-trivial tibio 
drawing, the verification process might involve hun- 
dreds or thousands of rule-checks. Without the advan- 
tage of an automatic rule-checker, it might take an ex- 
pert programmer hours or days to locate just one rule 
violation. Thus the tibio framework provides a very po- 
tent capability. 

[0098] Even though a tibio framework may be imple- 
mented using "hard-coded" routines, the tibio frame- 
work may be partitioned into separate sets of rules. 
Each set of rules may focus on rules that pertain to one 
aspect of a tibio drawing, for example: blocks. Further, 
it is possible that the code that checks a given set of 
rules be collected into separate tibio framework mod- 
ules. This leads to the concept of a tibio framework "ex- 
ecutive" routine that can call individual tibio framework 
modules as needed. As shown in Fig. 19E, tibio frame- 
work modules can be arranged in a hierarchy. Various , 
modules in the hierarchy may be replaced depending 
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on specific tibio drawing conditions. Consider a tibio 
drawing where one portion of the tibio drawing pertains 
to motor control, and another. section of the same tibio 
drawing pertains to speech recognition. (These differ- 
ences in focus are sometimes. referred to as different 
"problem domains".) In this example it is quite likely that 
the set of rules for wires in the motor control area will be 
different from the set of wire rules that apply to the 
speech recognition "circuitry". A tibio framework execu- 
tive is able to call the appropriate wiring-rule module de- 
pending on which section of the tibio drawing is being 
analyzed. Ths exact arrangement of the tibio framework 
modules in thi> tibio framework hierarchy may differ sub- 
stantially from the example given in Fig. 19E. 
[0099] In some instances a block may recommend a 
specific tibio framework to govern its operation. In other 
instances it may contribute its own set of rules that guar- 
antee correct results. 

[0100] Specialized (custom) versions of the GSDS 
may be designed with the tibio framework "hardcoded" 
into the GSDS code, in this case, the tibio framework 
would be fixed and immutable. In other case, the tibio 
framework may be a distinct module that can be re- 
placed by the user. In yet another case, the tibio frame- 
work may be implemented as tibio components that ap- 
pear in a GSDS drawing. 

I. tibio component Publisher 

[0101] The graphical solutions development system 
500 is based on the concept of the composition of sev- 
eral pre-engineered tibio components to provide a high- 
er-level solution. (This is analogous to bringing many 
mechanical components (engine, wheels, transmission, 
etc.) together to build an automobile.) The commercial 
success of the graphical solutions development system 
500 is predicated on widespread availability of tibio com- 
ponents. The graphical solutions development system 
provides a tibio component publisher to facilitate the cre- 
ation of tibio components that are fully compatible with 
other tibio components and the graphical solutions de- 
velopment system. ***Fig.20A heuristically shows the 
overall structure. 

[0102] The tibio component publisher may be imple- 
mented using a sequential user dialog construction (this 
is frequently referred to as a wizard), or it may be imple- 
mented in other ways such as embedding " tibio com- 
ponent-publishing" capability directly into a user-de- 
fined component. 

[0103] One example of a tibio component publisher, 
employing a wizard construct, is shown in Figs. 20B- 
20F. In this example, the wizard is configured as a 
tabbed dialog where the user can quickly and directly 
access the information on any tab. The first tab, Fig. 
20B, requests the tibio component author to fill in gen- 
eral information like the name, a description, etc. The 
"GUID" field is for a random number associated with this 
specific tibio component. The term "GUID" is actually an 



abbreviation for Global Universal Identifier. (GUID tech- 
nology is an established software standard.) In this 
case, the tibio component publisher automatically gen- 
erates the GUID which is a 128-bit identifier typically 

5 broken into five fields by hyphens and expressed in hex- 
adecimal. The tibio component publisher includes a 
symbol pane that provides a graphical view of the sym- 
bol that will appear in a GSDS drawing when an instance 
of this block is added. As the tibio component is defined 

10 and refined, using subsequent tabs of the tibio compo- 
nent publisher, this symbol will be automatically updated 
to represent the new tibio component accurately. 
[0104] The tibio component publisher may include 
graphical editing capabilities that permit the user to di- 

15 rectly modify the symbol. This might include changing 
size, changing colors, adding text fields, moving pin lo- 
cations, etc. Buttons at the bottom of the tibio compo- 
nent publisher permit the user to advance to the next 
tab, to retreat to previous tabs, or to cancel the publish- 

20 jng operation. The "Finish" button is enabled when all of 
the tabs are satisfactorily completed. The finish opera- 
tion is chiefly concerned with formatting the data prop- 
erly and storing it in a file. 

[0105] The vendor tab, Fig. 20C, collects pertinent 
25 vendor information. Other information could include ad- 
dresses, technical support information, phone numbers, 
etc. 

[0106] The interfaces tab, Fig. 20D, permits the tibio 
component author to add pins to the tibio component. 

30 For clarity, this tab provides a "treeview" of the pins. The 
tibio component creator may add any number of pins 
into each of the four possible interface categories: Data 
Input, Data Output, Event Input, and Event Output. (The 
treeview shown in this example refers to the four pin cat- 

35 egories using the labels "Input Signal", "Output Signal", 
"Input Event", and "Output Event" respectively. In Fig. 
20D note that three pins have been defined: an Output 
Signal pin named "Vout" and two Input Event pins 
named "IFreq" and "IVolume". 

40 [0107] The properties tab, Fig. 20E, allows tibio com- 
ponent properties to be added. Again a treeview is used 
to present the properties. Not shown, each property may 
have attributes. For example the signal frequency prop- 
erty, Fout, could have attributes "Fmax" and "Fmin" that 

45 could be used to limit the frequency range. 

[0108] The resources tab, Fig. 20F is the dialog where 
the tibio component author can insert any files that need 
to be added to the tibio component. In this example, note 
that in addition to the source files that have been dis- 

50 cussed, there is also a bitmap file (tilogo60.bmp) and 
three script files: OnAssemble.TSL, OnDeposit.TSL, 
and OnProperty.TSL. 

[0109] The tibio component author may use the tibio 
component publisher to "edit" an existing tibio compo- 
55 nent. In this case, the tibio component publisher will 
"read" the tibio component file and place all of the rele- 
vant information on the appropriate tibio component 
publisher tabs. The author may then browse and edit 
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the information as needed. Sometibio components may 
have a "locking mechanism" that prevents normal users 
from modifying a tibio component. 
[0110] * The tibio component publisher verifies that all 
essential information is included before it will produce a 
finished tibio component. One of the final steps in pro- 
ducing a tibio component is to create a software file and 
storing all relevant tibio component information in this 
file. The file may have a predefined, standardized for- 
mat. The tibio component publisher assures that tibio 
component file, which is the physical collection of all the 
data in the tibio component, is created and formatted in 
accordance with any applicable tibio component stand- 
ards. 

[0111] The tibio component publisher may use tibio 
framework rules and/or the tibio framework rule engine 
to assist in creation of a new or existing tibio component. 
This verif ication process provides a great deal of assur- 
ance that a tibio component will operate in a given tibio 
framework. A tibio component may be checked for com- 
patibility with more than one tibio framework. 
[01 1 2] An excerpt from a tibio framework script is giv- 
en in Fig. 21 . This code is designed to verify that each 
pin on a tibio component (or block) has a unique name. 
A pair of For/Next loops is used to iterate through all 
pins so that the name for each pin can be compared to 
the name of every other pin. Code 3801 queries the 
GSDS to determine the number of tibio componentpins. 
Code 3802 implements an outer loop that iterates all of 
the pins. For each pass of through the outer loop, the 
code of the inner loop 3803 iterates through all pins (that 
have not already been checked) and compares pin 
names to see if there are any duplicates. This example 
demonstrates that the expertise embedded in a tibio 
framework script can be leveraged each time that a new 
tibio component is created. 

J. Data Viewer 

[01 13] A typical tibio drawing is a composition of tibio 
components interconnected with wires. In such a tibio 
drawing, data and control information are processed to 
achieve a desired result or solution. Frequently for de- 
bugging or for verification of proper operation, it is ben- 
eficial to be able to inspect the operation of a tibio draw- 
ing at various points on the tibio drawing. The graphical 
solutions development system implements the concept 
of probes and data viewers to permit the user to visually 
display a representation of the data on any wire or pin. 
[01 14] The term "Data viewers" refers to a set of soft- 
ware modules where individual viewer modules can be 
added and older viewers can be replaced with newer 
versions. Adding or replacing viewers can be done at 
any time after the GSDS is installed. Also, certain tibio 
components may contain custom data viewers. In this 
case, the tibio component, when it is instantiated in a 
tibio drawing, may automatically add the viewer to the 
GSDS system. 



[011 5] Although conceptually it is easy to conceive of 
a data viewer providing a graphical representation of da- 
ta, similar to an oscilloscope, a data viewer may provide 
substantially different capabilities as well. For example 

5 a data viewer may provide an interactive window where 
the user can modify or simulate various operating con- 
ditions. This means that a data viewer, in addition to be- 
ing able to display the response at various points in a 
GSDS drawing, may also be able to provide stimulus to 

10 various points in a tibio drawing. 

[0116] Fig, 22A provides a screen shot 3900 of the 
GSDS showing a representative tibio drawing for a dual- 
tone multi-frequency (DTMF) signal generator. In this ti- 
bio drawing, two probes have been "inserted". An oscil- 

15 loscope probe 3902 is attached to a wire. This connotes 
that data from this wire is available for any suitable view- 
er. A second probe 3906 has also been attached to a 
wire. This probe, denoted by the loudspeaker icon, for- 
wards this data stream to an audio output device (e.g. 

20 a speaker). Probes provide a very convenient high-level 
debugging tool. Probes are invoked from appropriate 
toolbar buttons 3905 or from menu selections. 
[0117] Figures 22B, 22C show typical data viewer 
screens. In this case, Fig 22A provides a time-domain 

25 plot fo the signal on the wire being probed, whereas Fig, 
22B provides a spectral plot of the signal. 

K. Using the Graphical Solutions Development System 

30 [0118] In general steps in building a project include 
sequentially adding blocks of tibio components of vari- 
ous types to a tibio drawing and connecting, pins with 
wires. For example, a tibio component X from a remote 
location via the Internet may have design help files, the 

35 change in parameters of tibio component Y automati- 
cally changes parameters in tibio component Z, and a 
tibio framework may impose constraints on tibio compo- 
nent W. Recall Fig. 8B illustrates basic connections and 
one block influencing parameters of another block. 

40 

Further preferred embodiments 

[0119] The preceding has described how the GSDS 
leverages the intelligence of expert programmers and 

45 delivers powerful capabilities to both advanced and nov- 
ice programmers. Many GSDS concepts extend to more 
generic situations as indicated in the following sections. 
[0120] A. tibio component Packaging & tibio compo- 
nent File Structure The graphical solutions development 

50 software employs a standardized tibio component archi- 
tecture where a tibio component may be considered as 
a single composite formed by the aggregation of many 
different resources. (In many cases, resources can be 
thought of as files.) These resources are stored in a spe- 

55 cial archive file that is commonly referred to as a com- 
pound file, as illustrated in Fig. 24 and referred to as a 
Tlkitfile. Resources may be functionally segregated into 
several different categories including code modules, 
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configuration modules, and other miscellaneous files 
and resources. The graphical solutions development 
system includes a " tibio component resource" server 
that can locate and retrieve any resource in any tibio 
component. 

(i) Code Modules 

[0121] Code modules comprise all of the run-time re- 
sources stored in a tibio component. These resources 
may include source code, assembly code, object code, 
libraries, objects, code fragments, etc. The final run-time 
code that ultimately gets deposited into a solutions 
project is usually constructed using a subset of these 
resources. Source code modules may be encrypted to 
protect the commercial interests of tibio component de- 
signers. 

(ii) Configuration Modules 

[0122] This is the collection of all the script files, exe- 
cutables, code generators, etc that are stored in and 
delivered with the tibio component. This collection may 
include assemblers, compilers, linkers, or other special- 
ized build tools. These modules may provide configura- 
tion dialogs or other design assistance. Via scripting 
these modules can gather design information from both 
the user and the current tibio drawing. After gathering 
all pertinent information, the configuration modules con- 
struct a customized run-time file (or files) that is depos- 
ited into the appropriate solutions project(s). It is impor- 
tant to note that "customized run-time files" means that 
two instances of the same tibio component in a single 
tibio drawing may contribute completely different run- 
time code-depending on how they are used, what they 
are connected to, how their properties have been set, 
and other factors. The configuration modules are used 
primarily at design-time; hence these files are usually 
not part of the run-time code image. 

(iii) Miscellaneous Modules 

[0123] These are any other resources that the tibio 
component creator thought might be helpful to a user. 
These include help files, application notes, links to web 
sites, utilities, graphics, etc. These modules also repre- 
sent design-time resources. 

(iv) Class Properties 

[01 24] tibio components also contain a set of common 
properties referred to as "class" properties. Class prop- 
erties are properties that every tibio component is ex- 
pected to maintain. These properties provide a set of 
standardized data that includes the tibio component 
name, the tibio component vendor, the revision number, 
the revision date, tibio component description, as well 
as many other items. Most of these properties are set 



when the tibio component is created and are "read only" 
after the tibio component is published. Some class prop- 
erties may be modified by the user. 

5 (v) Self-Contained File Format 

[0125] All of the resources that are included in a tibio 
component are stored in a single compound file. If a user 
has a tibio component file, then there is great certainty 
that all necessary tibio component resources are avail- 
able. This very clean approach to tibio component de- 
ployment avoids a great many pitfalls and simplifies cop- 
ying a tibio component, deleting a tibio component, mov- 
ing a tibio component, selling a tibio component, etc. 
The entire tibio component-file strategy is optimized for 
web-based deployment. 

(vi) Self-Installing tibio components 

[0126] A tibio component can include many different 
resources (files). It would be cumbersome to have to un- 
pack all these resources and move them to special di- 
rectories. This would be prone to many errors during in- 
stallation. Additional errors would be likely when trying 
to move, or delete a tibio component. To simplify this 
situation, the graphical solutions development environ- 
ment implements a tibio component server that can 
fetch resources from any tibio component. With this ad- 
vancement, installation of tibio components is reduced 
to sjmply coping it into the designated" tibio component" 
directory. This eliminates setup; this eliminates config- 
uration. Since it is a single file, it is very convenient to 
move it, copy it, delete it, etc. 

(vii) Unique Naming Convention 

[0127] Tibio component files employ a unique naming 
convention that eliminates the possibility that different 
tibio component designers might create different tibio 
components but accidentally use the same name. Dif- 
ferent tibio components with the same name (a situation 
referred to as "name clashing") create confusion be- 
cause a tibio drawing may be expecting code from one 
but actually get code from a different (i.e. rogue) tibio 
component. When a tibio component is published (cre- 
ated), the tibio component publisher creates a random 
name. This filename is based on a Global Universal 
Identifier (GU ID). The use of GU ID technology reduces 
the probability to less than once in a million years. 

B. Intelligent tibio components 

[0128] The purpose of a tibio component is to encap- 
sulate and deliver some useful functionality (e.g. de- 
modulation, data encryption, filtering, etc.). A tibio com- 
ponent is created by an expert to provide a desired op- 
eration. The challenge is to provide the most robust ca- 
pability that will insure proper operation in every situa- 
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tion where this tibio component may be invoked. If in- 
stead of using a tibio component from the tibio compo- 
nent gallery, an expert were called each time the tibio 
component's functionality was needed, the expert would 
apply his own knowledge base of problem solving skills. 5 
Nominally, the expert explores the operating environ- 
ment to determine what processor will execute the code, 
how much memory is available, what is the format of the 
incoming data, what is the data format required for sub-, 
sequent processing operations, etc. After weighing all 
of this information along with the expert's personal ex- 
perience, the expert can write the appropriate code for 
a specific tibio component instance. 
[0129] Unfortunately, when a tibio component is cre- 
ated (published) it represents a fixed "package" of func- 
tionality that cannot be modified unless a revised edition 
of the tibio component is published. This tends to limit 
and restrict the versatility of a tibio component that, by 
definition, needs to properly interoperate with all other 
tibio components in every case. The ideal solution would 
be for a tibio component to encapsulate some of the ex- 
pert's integration knowledge so that the tibio component 
could instantiate itself in different ways depending on its 
operating environment. (The phrase "instantiate itself in 
different ways" means that the code that the tibio com- 
ponent contributes to a solutions project might be differ- 
ent, might be optimized in some way, depending on fac- 
tors external to the tibio component.) 
[0130] The graphical solutions development system 
comprehends and embodies the concept of a powerful 
scripting (programming) language. Scripts (i.e. pro- 
grams) written using the scripting language may be in- 
cluded in a tibio component. The scripting language pro- 
vides transcendentf unctions which can provide visibility 
into "environmental" properties like what processor will 
execute this tibio component's code, how much memory 
is available, what is the format of the incoming data, 
what is the format of the data required for subsequent 
processing operations, etc. The scripting language per- 
mits the expert (who creates a tibio component) to em- 
bed a significant measure of his (or her) integration 
knowledge into the tibio component. Based on the 
script's ability to interrogate the operating environment, 
the expert can embed integration knowledge to select 
(or build) the appropriate code modules and contribute 
them to the solutions project. The scripting language al- 
so provides a tibio component with visibility into nearly 
every facet of the environment including processor ca- 
pabilities, clock speed, memory properties, operating 
system properties, sampling rate, wire and pin informa- 
tion, task loading, as well as viewing and/or negotiation 
with all other tibio components on . a tibio drawing. Fig- 
ures 17G, 17H, and 171 provide clear examples of tibio 
component scripts where the tibio component engineer 
exercised the privilege of embedding personal expertise 
and integration knowledge into a tibio component. Note: 
The term "capturing integration knowledge" is a generic 
concept. Every script represents the embedding or cap- 



turing of an expert's integration knowledge. Hence eve- 
ry script shown is a representative example of an expert 
delivering encapsulated expertise within the tibio com- 
ponent. The OnProperty script of Fig. 1 7G delivers the 
expertise concerning which properties the user may 
want to be able to control. For this Sinewave generator 
the expert has decided that the user might like to be able 
to set the frequency and the amplitude. A different ex- 
pert might consider other properties more important. 
Continuing this example, the OnDeposit script of Fig. 
1 7H is used to copy the appropriate code files from the 
block to the project. Using this script, the expert delivers 
his expertise regarding which files are needed (based 
on user-configured property settings) and his expertise 
regarding which folders the various files should be cop- 
ied into. And lastly, the OnAssemble script of Fig. 171 de- 
livers the expert's knowledge of how to pass data or 
events from one tibio component to another (in accord- 
ance with the wires that interconnect the various tibio 
components). In almost every case, a script will be de- 
livering a nugget of expertise that the tibio component 
designer deemed to be important. Note that this helps 
create a competitive environment where one tibio com- 
ponent designer can try to offer improved tibio compo- 
nents with the only improvement in the scripts rather 
than in the actual DSP code modules. 
[0131] Fig. 23. gives the listing of a function called Au- 
toName 4000 to illustrate how a script may query the 
environment (in the particularcase, the tibio drawing en- 
vironment) to determine how to achieve a desired result. 
This function may be included in a tibio component.so 
that when it is instantiated in a tibio drawing that it can 
automatically pick a suitable unique name. A "short- 
name" is passed to this function when it iscalled. The 
"shortname" is an abbreviation for the tibio component; 
for example the "shortname" for a Sine Wave Generator 
might be "SIN". The purpose of this function is to analyze 
the tibio drawing and count how many instances of the 
current tibio component there are (e.g. SIN1 , SIN2, and 
SIN3) and automatically generate the proper unique 
name for the current instance (SIN4). To perform this 
task, the tibio component must seek information that is 
outside of the tibio component, i.e. it must examine the 
environment that it is being placed in. This process be- 
gins with statement 4002 where the tibio components 
queries for a pointer to the current tibio drawing. Code 
statement 4003 queries for the total number of blocks 
currently on the tibio drawing. Statement 4004 seeks a 
pointer to the current block, and statement 4005 queries 
for the name of the tibio component of which this block 
is an instance. The software loop 4006 creates an iter- 
ative process where each block on the tibio drawing to 
see how many instances of this same tibio component 
exist. During each iteration of the loop the statement 
4007 gets a pointer to the next (the "j-th") block. An "if" 
statement 4008 checks to see if the GUI D (i.e. the name) 
of the current block matches the GUID of the "j-th" block. 
For each match, an instance-count variable (named 
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"Comps") is incremented. The "AutoName" function re- 
turns a string that is the concatenation of the "short- 
name" and the instance count. 

[0132] Scripting provides capabilities for achieving 
compatibility (he. interoperability) as well as optimiza- 
tion based on user-defined goals. Specific capabilities 
(enabled via scripting) that may be useful include elim- 
ination of parameter range-checking, elimination of data 
format conversions, re-linking selected code modules, 
patching code fragments into object modules, etc. 
[0133] Tibio component scripts can be executed at 
design-time, at build time, or at run-time (or any combi- 
nation). There are a host of other design time "events" 
which may be used to invoke scripts. These include a 
property-change event, a new-wire event, a new-probe 
event, and many others. 

[01 34] The expert who creates a tibio component may 
decide to write the tibio component's code in four differ- 
ent ways. All four code modules can be placed inside a 
single tibio component at the time that it is published. 
However when the tibio component is used, the tibio 
component scripts determine precisely which code 
module(s) will provide the optimum functionality : and on- 
ly those modules are contributed to the solutions project. 
[01 35] Although scripts can enhance tibio component 
functionality, tibio components are not required to have 
scripts. Also, scripts are one way that a tibio component 
can "advocate" new rules to the tibio framework. 

C. Visual Paradigm based on Data and Control Flow 
[0136] ***Cf earlier on event passing 

D. Platform Components 

[01 37] The ultimate goal of the graphical solutions de- 
velopment system is to convert a user-generated block 
diagram on a tibio drawing into real and efficient proc- 
essor instructions (i.e. a code module) and load this 
code module onto a real piece of hardware. To properly 
perform this conversion process, a good bit of informa- 
tion is needed regarding the actual hardware where the 
code will be executed. Things that are important at build- 
time may include: 

Processor type 
Processor speed 
Memory map 
Memory speed 

I/O ports- types, locations, properties 

Properties of the software kernel 

Properties of the real time operating system (RTOS) 

Debugging information 

Utilities for testing 

Special compilers or other code-generation tools 
Tibio .framework rules that apply to this specific 
hardware implementation 



[0138] There needs to be a simple way to capture all 
of this information and make it easily accessible both to 
the graphical solutions development system as well as 
to all tibio components on the tibio drawing. In the pre- 
5 ferred embodiment, this is resolved by abstracting the 
platform as tibio component. A platform tibio component 
is similar to other tibio components in that it is represent- 
ed as a block on a tibio drawing, and it can contain many 
different files. The platform tibio component contains a 
w description of all of the hardware features. This descrip- 
tion is captured in a compatible file format so that this 
information is available to the visual tibio drawing editor 
for on-the-fly rule checking during the design process. 
[01 39] Placing all of the relevant information for a giv- 
15 en hardware platform in a platform tibio component 
solves many problems. In a tibio drawing this serves as 
a single repository for all hardware information. Be- 
cause the platform information is implemented as a 
" tibio component" in the tibio drawing, all other tibio 
components injthe tibio drawing have access through 
the power of the scripting language. 
[0140] The graphical solutions development environ- 
ment includes the concept of a specialized " tibio com- 
ponent publisher" utility specifically designed and opti- 
mized to publish "platform components". 
[0141] Benefits: same paradigm as all tibio compo- 
nents/can have any needed resources /can be queried 
from scripts 



[0142] Regarding tibio frameworks, the data that com- 
prise the rules and the rule engine may be physically 
distinct, or they may be "hard-coded" into an integrated 
35 implementation. A hard-coded implementation makes it 
more difficult to change rules, but this disadvantage is 
offset by enhanced execution speed. 
[0143] Fig.1 9A gives a listing of several possible tibio 
framework rules that pertain to blocks. Each rule is as- 
40 signed a "Rule Number" that is a convenient reference 
designator. The first rule, "B000", states that every block 
on a tibio drawing must have a solutions project at- 
tribute. Because the GSDS only understands how to 
"build" and "run" projects, any block that intends to par- 
45 ticipate must have a proper designation indicating to 
which project it is assigned. 

[0144] The script code shown in Fig. 19B implements 
a function that verifies whether or not, for all the blocks 
in a given project, rule "B000" is satisfied. Code 2901 

50 queries the GSDS to determine how many blocks are 
currently in the project. Code 2901 initiates a software 
ioop that enumerates each block in the project. Code 
2903 calls the 0 VerifyAttributeExists ,, API to determine 
if each block has a "Project" attribute. This example 

55 script demonstrates how a software function can be con- 
structed to verify that a rule is satisfied. 
[0145] In Fig. 19C, the listing illustrates that a soft- 
ware subroutine can be implemented to iterate through 
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the entire set of "block" rules. In this simple example, 
each rule violation generates an error message to the 
user. There are many alternate methods of handling er- 
rors including logging them in a file, automatically cor- 
recting them, etc. 5 
[01 46] A complete tibio framework example is provid- 
ed in Fig. 1 9D. This tibio framework script code sequen- 
tially calls subroutines that verify rules for the work- 
space, the project, the blocks, and the wires. This simple 
example is somewhat deceptive. If a more robust tibio 10 
framework were invoked to "examine" a non-trivial tibio 
drawing, the verification process might involve hun- 
dreds or thousands of rule-checks. Without the advan- 
tage of an automatic rule-checker, it might take an ex- 
pert programmer hours or days to locate just one rule 15 
violation. Thus the tibio framework provides a very po- 
tent capability. 

[0147] Even though a tibio framework may be imple- 
mented using "hard-coded" routines, the tibio frame- 
work may be partitioned into separate sets of rules. 20 
Each set of rules may focus on rules that pertain to one 
aspect of a tibio drawing, for example: blocks. Further, 
it is possible that the code that checks a given set of 
rules be collected into separate tibio framework mod- 
ules. This leads to the concept of a tibio framework "ex- 25 
ecutive" routine that can call individual tibio framework 
modules as needed. As shown in Fig. 19E, tibio frame- 
work modules can be arranged in a hierarchy. Various 
modules in the hierarchy may be replaced depending 
on specific tibio drawing conditions. Consider a tibio 30 
drawing where one portion of the tibio drawing pertains 
to motor control, and another section of the same tibio 
drawing pertains to speech recognition. (These differ- 
ences in focus are sometimes referred to as different 
"problem domains".) In this example it is quite likely that 35 
the set of rules for wires in the motor control area will be 
different from the set of wire rules that apply to the 
speech recognition "circuitry". A tibio framework execu- 
tive is able to call the appropriate wiring rule module de- 
pending on which section of the tibio drawing is being 40 
analyzed. The exact arrangement of the tibio framework 
modules in the tibio framework hierarchy may differ sub- 
stantially from the example given in Fig. 19E. 
[0148] In some instances a block may recommend a 
specific tibio framework to govern its operation. In other 45 
instances it may contribute its own set of rules that guar- 
antee correct results. 

[0149] Specialized (custom) versions of the GSDS 
may be designed with the tibio framework "hardcoded" 
into the GSDS code. In this case, the tibio framework so 
would be fixed and immutable. In other case, the tibio 
framework may be a distinct module that can be re- 
placed by the user. In yet another case, the tibio frame- 
work may be implemented as tibio components that ap- 
pear in a GSDS drawing. 55 
[0150] Benefits of tibio frameworks: 

■ Makes life easier for beginners 



■ Reduces/eliminates errors 

■ Improves performance 

■ Encapsulates intellectual property 

[0151] These facts are important. 

■ Tibio frameworks may be tibio components 

■ Tibio frameworks may be aggregates of smaller ti- 
bio frameworks 

■ Tibio components may add rules to a tibio frame- 
work 

F. Real-time Extension to Microsoft COM 

[0152] The Component Object Model (COM) is a Mi- 
crosoft standard that is designed to facilitate how soft- 
ware components can intemperate in a generalized or 
generic way. This is a very powerful standard, and is 
used to provide unique capabilities in Tibio. Further, be- 
cause Tibio has a view into the Tibio drawing, the tibio 
framework, and the platform, COM can be slightly mod- 
ified or extended to provide many substantial benefits. 
In Fig. 22A the event wires (between the tibio compo- 
nent-instance blocks and the COM (Server) block) 3903 
are implemented using COM technology. The wire con- 
necting the Host Application (not shown in Fig 22A)?to 
the Com Server block 3903 is also implemented using 
Com technology. The following comments pertain to the 
way that COM is used and implemented in Tibio (these 
should be reviewed for patent protection): 

1. A Tibio drawing can automatically generate a 
COM interface server that provides the host appli- 
cation with a custom interface to every event wire 
in the tibio drawing. 

2. Every event wire that is connected to the COM 
Server 3903 block defines a portion of the COM in- 
terface that is created. 

3. There are three types of interfaces that can be 
added: scalars, function values, and COM interfac- 
es. 

4. The GUID of the COM object represents the ac- 
tual target code that the tibio drawing generates. 

5. The interface GUID corresponds to the unique 
interface that the host uses to communicate with the 
COM object. 

6. Subsequent changes to the event wires in the Ti- 
bio drawing will modify the interface to the host. 

7. Both input events and output events of a DSP 
tibio component can be modeled using COM. 

8. Tibo components' input events add methods and/ 
or interfaces to the COM object 

9. Tibio components' output events add COM 
events to the COM object 

10. The COM threading models are extended for 
asymmetric processing 

11. Since we are generating a custom interface for 
a DSP target, we can create custom interfaces that 
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are optimized for the specif ic hardware. (Especially 
for shared memory model.) This was previously dis- 
cussed in section on events. 

12. Normally COM interfaces generate specific 
code for each method exposed, but Tibio has ac- 
cess to system and context knowledge it can gen- 
erate much more efficient methods than a generic 
approach. This typically enhances execution 
speed. 

13. To accommodate the real-time nature of DSP 
processing COM needs Tibio can extend COM. 
This requires synchronization of processing tasks 
and other optimizations. 

[0153] Benefit: COM is a standard that is used by a 
million Windows programmers every day. (Note that Mi- 
crosoft defines a COM component slightly differently 
than the way we define a Tibio component.) COM pro- 
vides very significant benefits of: 1 ) provides a standard 
for how to write COM components, 2) COM components 
are used in a standard way, regardless if they are run- 
ning on the same processor, or are running on different 
kinds of processors at remote locations, 3) COM com- 
ponents can be written in any language, 4) COM in- 
cludes optional security protocols, and 5) compatible 
with a variety of network protocols. By using COM as an 
interface to DSP tibio components and DSP tibio draw- 
ings, it permits a million programmers to access com- 
plex DSP technology without having to learn anything 
new. This permits them to use familiar techniques to add 
incredible new features that are only available from 
DSP. The tact that the GSDS leverages COM gives them 
access to DSP with them having to spend several years 
trying to master DSP technology. This strongly supports 
the initial Tibio goal of "packaging the expertise of DSP 
programmers and delivering it to the millions of Win- 
dows programmers". 

[0154] The screen shot of Fig 22A shows a tibio draw- 
ing composed of several different blocks. In this tibio 
drawing, several of the various block's event pins are 
connected via wires to the COM block 3903. This COM 
block provides a very special functionality. The purpose 
of the COM block is to automatically define an standard 
interface to each of the blocks that is attached to it. In 
this case, the standard interface is a Microsoft COM in- 
terface. Microsoft's public documentation on COM spec- 
ifies precisely how a COM interface is defined. Once the 
COM interface is defined, it provides a standard way for 
any Microsoft Windows program to access the function- 
ality of the tibio drawing. In other words, just by connect- 
ing the various event pins (on the tibio drawing) to the 
COM block 3903, a standard interface to the DSP func- 
tionality is automatically generated. This permits the us- 
er to instantly expose this DSP functionality to a huge 
audience of potential users. 

[0155] Every wire in a tibio drawing is represented in 
the GSDS as an object with a set of properties. Proper- 
ties include which pin of which block is connected to 
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each end of the wire. It is very easy for the COM block 
to iterate through the collection of wires and query each 
wire object and determine the blocks that are attached 
to it. With this block and pin information, it is a simple 

5 process to query each of the attached blocks to deter- 
mine what event protocols or methods each block needs 
for proper operation. COM interfaces are defined by 
composing a description in a special interface definition 
language (IDL). Once the interfaces (that need to be ex- 

10 posed) are determined, it is a simple matter to translate 
this into the corresponding IDL file. 

G. Smart Probes and Viewers 

15 [0156] To test, verify, measure performance, or debug 
a tibio drawing the concept of probes is included in 
GSDS. It is important to note that probes (even in graph- 
ical circuit representations) are not new. The innovation 
that GSDS=Tibio brings to this scenario is the concept 
20 of smart probes based on the ability of Tibio to view the 
entire design context including the tibio framework, the 
hardware platform, the individual tibio components and 
the way that the tibio components are interconnected. 
[0157] The following comments pertain to why Tibio 
25 offers unique probing capabilities. 

1 . Tibio is designed for applications programmers 
and for DSP novices who want to get the most rel- 
evant information in the quickest and easiest way. 

30 Smart Tibio probes facilitate access. The term 
"smart probe" refers to a feature of the GSDS 
where, when a probe is attached to a wire, the 
GSDS can query the properties of the wire to deter- 
mine the type of a data that the wire is routing. 

35 Based on the type of data, the GSDS can provide 

a list of compatible data viewers. 

2. Abstract-data probing refers to fact that the infor- 
mation that would be most helpful may not exist an- 
ywhere on a Tibio drawing. But perhaps some math- 

40 ematical or temporal processing of data that is avail- 
able can be used to derive a more useful view of 
abstract data. 

3. Tibio uses the entire context of the Tibio drawing 
along with real-time data exchange (real-time data 

45 exchange or "RTDX" refers to a technology devel- 
oped by Texas Instruments to provide a real-time 
hardware data-port into an operating microproces- 
sor) to create a view that is friendlier to a novice 
programmer. 

so 4. Probe hooks (i.e. special probe points) can be 
placed inside a tibio component to provide more 
useful data than may be available from the tibio 
component pins or interconnecting wires alone. 
5. Placement of a probe on a tibio drawing gives the 

55 complete context of the probe needs, and automat- 
ically sets up all viewer functions which may include 
the RTDX channel and/or other debug hardware on 
the processor chip. . 
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6. Probing a data wire requires a tibio framework 
context. Tibio can supply this context automatically 
to insure that the data is properly captured, format- 
ted and displayed. 

7. Probe scripts can be used to capture the exper- 
tise of a libio component engineer of libio frame- 
work engineer and deliver this expertise to Tibio us- 
ers. A probe script may deliver the expertise that 
defines how a viewer's settings should be config- 
ured for optimal visual presentation. This may in- 
clude visual cursors on the viewer screen that de- 
note acceptable signal levels, etc. 

[0158] Insofar as embodiments of the invention de- 
scribed above are implementable, at least in part, using 
a software-controlled programmable processing device 
such as a Digital Signal Processor, microprocessor, oth- 
er processing devices, data processing apparatus or 
computer system, it will be appreciated that a computer 
program for configuring a programmable device, appa- 
ratus or system to implement the foregoing described 
methods is envisaged as an aspect of the present in- 
vention. The computer program may be embodied as 
source code and undergo compilation for implementa- 
tion on a processing device, apparatus or system, or 
may be embodied as object code, for example. The 
skilled person would readily understand that the term 
computer in its most general sense encompasses pro- 
grammable devices such as referred to above, and data 
processing apparatus and computer systems. 
[0159] Suitably, the computer program is stored on a 
carrier medium in machine or device readable form, for 
example in solid-state memory or magnetic memory 
such as disc or tape and the processing device utilises 
the program or a part thereof to configure it for operation. 
The computer program may be supplied from a remote 
source embodied in a communications medium such as 
an electronic signal, radio frequency carrier wave or op- 
tical carrier wave. Such carrier media are also envis- 
aged as aspects of the present invention. 
[0160] In view of the foregoing description it will be 
evident to a person skilled in the art that various modi- 
fications may be made within the scope of the invention. 
[0161] The scope of the present disclosure includes 
any novel feature or combination of features disclosed 
therein either explicitly or implicitly or any generalisation 
thereof irrespective of whether or not it relates to the 
claimed invention or mitigates any or all of the problems 
addressed by the present invention. The applicant here- 
by gives notice that new claims may be formulated to 
such features-during the prosecution of this application 
or of any such further application derived therefrom. In 
particular, with reference to the appended claims, fea- 
tures from dependent claims may be combined with 
those of the independent claims and features from re- 
spective independent claims may be combined in any 
appropriate manner and not merely in the specific com- 
binations enumerated in the claims. 



Claims 

1. A visual development method for an application 
program, comprising the steps of: 

5 

(a) displaying first and second blocks instanti- 
ating user selected first and second develop- 
ment components, said first block including a 
first prefabricated program, said second block 

10 including a second prefabricated program; and 

(b) . automatically creating, in response to user 
input connecting said first and second blocks, 
proxy and stub code for communication from 
said first prefabricated program to said second 

15 prefabricated program as parts of an applica- 

tion program. 

2. The method of claim 1 , further comprising the steps 
of: 

20 

(a) displaying third block instantiating user se- 
lected third development component, said third 
block including a third prefabricated program; 
and -s 

25 (b) automatically creating, in response to user 

input connecting said second and third blocks, 
proxy and stub code for communication from 
said second prefabricated program to said third 
prefabricated program as parts of said applica- 

30 tion program; wherein said communication 

from said first prefabricated program to said 
second prefabricated program is of control in- 
formation and said communication from said 
second prefabricated program to said third pre- 

35 fabricated program is of data. 

3. The method of claim 1 or 2, wherein: 

(a) said first prefabricated program runs on a 
40 first processor; and 

(b) said second prefabricated program runs on 
a second processor with said second processor 
differing from said first processor. 

45 4. The method of any preceding claim, wherein: 

(a) 'a development framework creates said 
proxy and stub code. 

5. The method of any one of claims 1 to 3, wherein: 

50 

(a) said first block creates said proxy code; and 

(b) said second block creates said stub code. 

6. A method using a visual development environment 
55 for creating a program for a programmable digital 

signal processor, comprising the steps of: 

(a) displaying first and second geometrical 
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shapes corresponding to user selected first and 
second components, said first component in- 
cluding at least one prefabricated program for 
a programmable digital signal processor, said 
second component including at least one pre- 5 
fabricated program for said programmable dig- 
ital signal processor; and 
(b) automatically creating a program for said 
processor in response to user input connecting 
said first and second geometrical shapes, said 10 
program including said first prefabricated pro- 
grams modified in response to the presence of 
said second prefabricated program. 

7. A computer program comprising computer program *5 
elements for configuring a computer to implement 
any preceding claim. 

8. A computer program comprising computer program 
elements translatable for configuring a computer to_ 20 
implement the method of any one of claims 1 to 6. 

9. A carrier medium carrying a computer program ac- 
cording to claim 7 or 8. 

10. A software tool for developing an application pro- 
gram, comprising software elements for: 

(a) displaying first and second blocks instanti- 
ating user selected first and second develop- 30 
ment components, said first block including a 
first prefabricated program, said second block 
including a second prefabricated program; and 

(b) automatically creating, in response to user 
input connecting said first and second blocks, 35 
proxy and stub code for communication from 
said first prefabricated program to said second 
prefabricated program as parts of an applica- 
tion program. 



45 



50 



55 



22 



BNSDOCID: <EP 1186997A2J_> 



EP1 186 997 A2 



100 



101 



Central 
Unit 



102 



Main 
Memory 
System 



Plotter 



LAN 
Card 



103 



Keyboard 



104 

Input-Output 
Controller 



105 



105 



Modem 



Sound 
Card 



108 



109 



110 



111 



112 



Dteptoy 
Device 



Pointing 
Device 



107 



Storage 



FIG.l 
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Block diagram of Main Computet System connected to secondary Processing Systems. 
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FIG* 3 



Block diagram of a Secondary Processing System. 
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Block diagram of Mm Computer OS, Windows services, application software, and GUI. 
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Block diagram of Main Computer System and Ttbio connected to secondary processing systems. 
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607 



Ready 




DACI 



C31DSK 



1403 words left 



601 



60S 



605 



609 



60S 



FIG. 6 



i Screen shot showing generic screen 
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501 



Component 
Pubfithor 



E 




Component 



502 



500 



50B 



Data 



507 



Component Assembly Tool 
(inaucfing primary user interface) 



Component 
Gallery 



Build 
TootS 



503 



505 



506 



FIG. 7 



Out-fHe(s) 



77 



Fremevrorfc 



504 



Block diagram of Graphical Software Development System. 
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70Q 



701 

702 



703 





706 



Fllter03 




704 



705 



FIG.SA 



| Visual representation of * component on the screen shows pins for wire connections. 
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Property Nnme 


Property Value 1 


Component Name 


lowPass Fitter 


Filename 


f53108000-5BFB-llD2-B9El-00600892CD76>.tik 


Component Category 


Telephony 


Component website 


tmitiwwvt.WiioxDm 


Release Date 


4-22-99 


Revision 


1.0.03 


Vendor Part Number 


Tibio-00 1-00461 


Vendor Name 


Texas Instruments Inc. 


Vendor Website 


htto : //wvww.ti.eom 


Processor 


TMS320C5410 


Framework 


Tetephony-S4-C 


Sample Rate Max 


8000 


Sample Rate Min 


8000 


Input Freauencv Max 


3.1 kHr 


Input Frequency Min 


0 


Passband Gain 


0.0 dB 


Cutoff Frequency 


1.2 kHz 



FIC8C 

100 



Table showing example properties and property values for a low-pass filter. 
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900 



901 



Component 
Properties 



902 



Vendor 
Information 



903 



Source 
Code 



904 



Object 
Code 



905 



Utilities 



906 



Help 



907 



Configuration 



908 



Data Viewers 



FIG.8D 



Simplified Block diagram of things in a Tibio component. 
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1001 



1000 



1002 



1003 




Frequency 



Cutoff Frequency 



SUOER02 

1010 



ion 




FIG. 9 



| Complete block diagram showing data flow and control flowT 
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1101 



Buffer A 



1102 



Buffer B 



1103 



Processor 
(including algorithm) 



1104 



Output Device 



FIG. 1 OA 



Block diagram of processing operation with real-time deadline. 



A new buffer of 
real-time data 
arrives every ten 
milliseconds. 



1201 
i 



10 



1203 



Processing Time >4- 



1202 
i 



Real-time Deadline 



FIG. 10B 



Timing diagram of real-time deadline 



1201 



10 msec. 



1202 



Real-time Deadline 



II 1 


1 




(■Ml 




WWW 



■ 

Processing Time 



1203 



FIG. 10C 
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1300 



1304 



To 
Modem 



Input Event | 
Off-Hook 



Output event 1 

Ring 1 



Transformer 



1301 



1306 



1307 



1302 



Ring Detector 



I 



1303 



Hook Relay 



1305 

i " 

i 



To 
Telephone 
Line 



FIG 11 



Hardware component 
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1400 



1401 



1403 



1402 



General Purpose 
Communication 
Channel 



1404 



1405 



Xfcita In r 



1407 



IE 



BedncaBy Programmable 
Logic Device 



Data Out 



1408 



FIG. 12 



| Progfammable logic component 
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1500 



lie Example 1 lib - TIBIO CAT 


HEE3I 


Fie £* Ifiew firawing UMp 




D|a?|Hr * j^.|©| □! 





SPiCBf I fcL 



DAC1 



Text Bern 



C31DSX 



Ready 



^r 1 



1501 



1502 ; 



1503 



1504 



FIG. 13 



Annotation component 
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1600 



1607 



1605 



1606 



1 1602 ] 



Component Editor 



Hb Edit Component 
RSDspPro 



E~C& Indudo 

Cb FurwX.h 
E-& Source 

Cb FurwXc 



troid PuncXInit () ; 
void FuncXProeess ( ) 



1604 



FIG. 14A 

| User code block 
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aal Exumplel.tib - TIBIO CAT HHE3 




Id _J JJ 

Rwdy ; V |403 worts teft 



FIG. 14B 
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1300 



-Select niter Conifgunatfon 




OK 



Cancel 



FIG 15 



Screen shot of property dialog window for a FIR filter. 
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1400 



4. Signal Generator 



-iftttance- 



Namc 



[SigGefil 



rV/avtrfotm- 



1401 



il 



C Sine Wave 
(* TrianojeWave 
C* Square Wave 




Waveform Option Box- permits 
the user to select any one of the 
three possible waveforms. In 
tins case the user has selected 
the "Triangle Wave** upturn. 



FIG. 16A 



Complete block diagram showing data flow and control flow. 
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1500 



i.WI i;<JOKY 


ui:s(H utt: 1 


Header Files 






Siae.h 




TriiagleJi 




gquarcJi 


Source Files 






Since 




Triangk-c 




Square.c 


Object Files 






Sme.obj 




Trianglcobj 




Square.obj 


Help Files 










Tmagleiilp 




Square Jilp j 


Script Files 






[Essiisau^MsW 




OnUnk.TSL 




OnRun/TSL 







FIG. 16B 
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1600 



On>rop*rxy script for 



Signal awerwor 



Din SeleetadMavef orm as Less 

Coast £iae - 1 

Const Triangle ■ 2 
Coast Square - 3 
Const OK • -1 

Cmst CANCEL • 0 

Result - 8to»ovPropertyDielog . 
fislsct ClM R«0ttlt 



pProject - OetMyProj ect 

Select Case select edWavef on* 
Ca.se Sine 

CopyPUeToProj eet. siee.fe, pPro j ect 
CopyPileTeProject lias.c, p Project 
CopyPileTorx-ojcct sij&euotoj, pProject 
Case Triangle 



1601 



1602 



CopyFllaTOProject triangle. h, p Project 
CopyPileToProjeet triangle, c, pprojeet 
CefpyP±leToPr©$eet triangle, obj , pProject 
Case Square 

CopyPileTo Project square .h, p Project 
CopyPileToProjeet s^omcc, pProjsct 
CopyPileToProject square .abj, pprejeet 
Sad Select: 



! 1603 



Case CANCEL 
d Select 



1BQ4 



function Showpropert / Dialog 

cods here to generate tae property dialog window 
(also sets Select adMavaforn variable) 

Knd Pusetioo 



r 



FIG. 16C 



Example of component selecting code bated on properties. 
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1700 



=s'. Bi.-dt3.tib - riuiu CAT BBB 



fie yigw flrwwng Xaqgt £ufefahy» Hejp 



Djgjgj oINnj g| ~j ✓tela! atel 




»»a» I INUM| /i 



FIG. 17A 



| Example Tibio drawing? 
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1800 



Sinn Wave Gentii«jtof 



Set Properties^ 

. ^ ■ •* ... 

Name jSINI 
Label 



Viirt Jo!5 



OK ) 



Cancel 



F1G.17B 



Example property dialog window for a Sine wave generator. 
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1900 



: Al li Uluvk 



Set Properties - 



Name |ALU1 
Operation j VI ♦ V2 jj 



OK, | 



Cancel 



FIG. 17C 



Example property dialog window for an. 



logic unit (ALU). 
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2000 



! Digital lo Anotocj Convcitei 



TLC3204Q UAG 




OK 



Cancel | 



109 



FIG. 17D 



Example property dialog for a Digitml-to- Analog converter (DAC). 
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2100 



C31DSK Plalfuim Piopcitius 



p Kernel Components- 

n Timer 1 • 
F Serial Port 

r DMA, . 



L 



OK 



1 

Cancel j 
Help | 



j- Kernel Select 
! r Kernel 



<? Kernel +DMA 



FIG. 17E 



Example property dialog for a C3 1DSK platform component 
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2200 



liJcr Block 



pSet Properties- 



Name frequency 



i 

! 



Maximum |3000 



Minimum [ISO ' 
Orientation | Horizontal 



I 0* I 
Cancel | 




FIG-I7F 



[ Example piopctiy dialog for a slider block. 
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OnProperty script for a Sine Wave Generator: (begin Fig 17G) 



• — OnProperty Script fox Sine Generator 
■ coop Vase t Sine Generator 

' COOp GUZD XXX 

« Plat tons Tr C31 DSK 

• Prameworic C3 ID CT> Aud i o 
' Revision r 1.0 

» Data ; 11-19-5S 

• Coop Engineer : John Tibbits 



2300 



Option Explicit 
Canst OK • -1 

Canst CAMCEL - 0 

Dim Result As Lang 
Din pTnieBlock as Long 
Din BnpPath£ 
Din cBHVX* 
Din Logo$ 



pointer to this component instance 
path tor BMP filse 
file name for bop in component 
fully qualified patn no TX logo 



Tki» in the subroutine that Tibio calls 
oleic? need* no be displayed. 



whenever the property 



InitVariablea 
ExportFile* 



initialise any arrays or variables 
copy any files to a temp dir 



Code belov generates a dialog window 



r 



Begin Dialog Dialog_l 15. IS, ITS , 102. "Sine Have Generator". .DlgPunc 



2301 



GroopBox 4.6,110.90, »Sat Properties" 
Text 18,24,48.12, "Han** 
Tajet 18,43,48,12, "Label" 

Text 18,60,48,12. 
Text 18,76.48,12, 
TeXtBox 44,22.50.12, 
TeXtBQX 44,40,50,12, 
TextBox 44. S8. 50, 12, .Pout 
TextBox 44,76,50,12, .Vout 
Picture 129. S6, 32, 32, Logo$, 0, .Logo 
OAutton 126,10,38,11 
Caneelnuccon 128.26,38,11 
V End Dialog 

Die Dig As Dialog_l * instantiates a dialog 

Dig . InstancnHane - BUCjQetProperty (pThiaBlock, "Maasa") 

• eet default properties 



2302 



- -untitled" Then 

- "SIH1» 

- "440" 

- "0.5" 



if Dig. last encettan 
Dig . Xnetancelta 
Dig. Pout 
Dig. Vout 

Kiss ' get current properties 

Dig. Label » BXJCjBetProperty IpThlsBlooX, "Label") 
Dig. Pout - BLX_Oet Property (pThiaBlocx. "Pout") 
Dig. Vout - BLKjaetProperty (pThlsBlocJc. ■Vout") 

sad If 
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Result « Dialog (Dig) ' display, the dialog box 

Select Cape Result 

_ Case OK . * Bind properties to Tibio 

230 J BUt_Set Property pThisBlock, »Hs»sV Dig . IxujtanceNam* 

BLX_Set Property pThiaBlock. -Label", Dlg.Laoel 

BlJC^Set Property pThiaBlock, "rout-. Dig. rout 

BUC_SetProperey pThleBlock, *Vouf\ Dlg.Voat 
cue au ran* 
Bad Select 

Bad 

The dialog box used above calls DlgPuac whenever the dialog 
window la open. Tnli runc tlo aa monitors the mouse and 
keystroke activity in the dialog box so that approp riate 
actions can be taken. 

Function DlgPunc (Control ID As String, Action As Integer, Suppvalue As Integer) 
Const IVITXALX2Z • 1 
Const MOUSECLXCK • 3 
Select Ceee Action 
Case » XHXTXA1»X2B 

DlgSetPicture "LogoV Logo* 

Case - HOUSBCX»XCX 
tad Saleot 

End Function 



Suli Initvarlables 

■ _______ _ — _»__.___..»......». 

initialise any variables or arrays 



pThieBlock - TSL_GetThi.aBlock 

csnrxs m "tilogoGQ.isap" 

BnxpPatn* » TSL_GetPeth < *TIBIO\TBMP" ) 

Bod Sub 

• . ^ 

Sub ExportFiles 

Export any files that nay be needed . 



LogoS - BepPeta* * »\e a cBMPIS 

Result ■ TSL_RxportResource ( cBXPl$ , Logo$) 

Cud Sul» 

..... . End of File 

FIG. 17G 
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OnDeposit Script for Sine Wave Generator (begin Fig 17H) 



2400 



OnDeposit Script for Sine Wave Generator 



Option Explicit 

Din pThisBlocIc As Long 
Din pWork space As Lang 
Din pPru j ect As Long 

Function OnDeposit () As Integer 



pointer to tbie cosponent iaatance 
pointer to this workspace instance 
pointer to tbie project instance 



Thm QnDopoait function for every block is cm lied early in the 
* Build*' process to give each block an opportunity to contribute 
any files I source, bender, libraries, dUs, assembly, etc.) to 
the project. 



c 



pThisSlock « TSL. GetTbisSlocXO 
2401 | pWorkspaee - TSLjOetTnlsWorkspaee ( ) 

pProjsct • WRK_Oet?ro j ectByHane (ptforkspace . "DspProcess** ) 



Conditional ststi 
inserted bare if 



at s, based on property settings, nay be 



Bare is syntax tor star 
FRj^AddReeource Project, 



•rile. 



Folder. 



Dest-File) 



2402 



PRJ_AddSLe*ouxee 
PAJ~AddRe»ource 
PRj_AddResource 
PRJ^Addfteeource 
PRj_AddRe»ouree 
Pttj"*AddReeourc e 



pFroject, pfnlsBlodt, 

p Project , pmisBlocX, 

pFroject. pTHisBlocX, 

pProject. pThiaBlocJc. 

©Project, pTbisBlock, 

p Project, pTIULsniock, 

psro j ect , pTbisBloek, 



'Sinoen.obj-, 
'Feed&acX.obj* 
•SinGen.h-, 
■SinQen.cV 

b«. 



-Object-. 

"Object 

"Include , • 



» I nc l ude " 



•nach.h- 



" Include- 



"SinGen.obj" 

■reedBacJc.obj" 

-SinGen.b* 

■ Sin Oen e* 

"FeedBacfc.fc* 

-PcedB*ok.c" 

'Math.h 0 



OnDeposit • 1 
End Function 



tnd of File 



FIG.17H 
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OnAsscmble script for a Sine Wave Generator: (begin Fig 1 71) 

2500 

OnAeeewble Script for Sine Wave C«&«ntor 

» _ _ _ _ _ _ — ~ ~ ~ 

Option Explicit 

Dim pThio Block Ae Long 
Oia pWorkSpacc Ae Long 
Ola pProject Ae JUong 
Dim pPregnentNep A* Irfing 

Dim ppln as bong 
Oia pwir* As liong 
Dim Proceee$ 
Dim ProceeeAS 
Oia VoutS 
Dim rreqlsCoe* 

Dim VolttMlnCOQi$ 

oia propfoutS ~" ~ ■ • - 

Oia PropVoufc? 

Oia DeclareA* 

Oia Declares* 

oia DeelareCS 

Oia lnit$ 

Oia Block tt —* 

Oin rreqVarllaaeS 

Ola VolumeVartiemeS 

Const SvPreq - Q 

Coaac Wbevml - l 

Function onAaaeeble () Ae Integer 

• Oat nana* of block an poincere to block, project 



pThisBlock = TSI*_GetThieBl©ek<) 

BloCkHewe$ - BUCGetPrxrperty (pTiili Block . -feiaae«) 
2S01 pMorkjpaca - TSL JJetTui»Work»pace < ) 

| pProjcct • VRX~GatProj *ctOyfeJ«m < pworkapece , "DepPxoceee*) 



Get the variable none of the wire (a) that era 
connected to the output of the aine wave generator. 



pPin • BXJC GetDaraOutByIiidax<pThiBBlook. 0) 
2502 pwire «= PDi_GetWixeByindex (pPin, 0 ) 
Vouta - KXft Oetvacnaaa tpWlre) 



Gat initial property value D for the frequency and 
output level, aa aat by tne uaex, free the property 
dialog window . 



CP rap Tout 5 - BUC_0et Property (pThiaBlock. 0 Fout*) ' Initial frequency 
PropVout* ■ BUC_Cet Property (pThraBlock , w Vout* ) * initial output level 



Build unique variable name* for the input eve&tt. 
Since block name are by definition unique, theae 

event variable names u* gaaaxafced. uaisag tb» block 
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2504 



pPin ■ BLXjOe t Input Event By Index (pThisBlocie, EvPreq) 
rrea^nCom* ■= PItf_GetFlnfefeae IpPia) 



pPin - BUC_Get Input Event By Index (pThisBlock. 
VolemeXnCew* - PIK_OatFi nwwme (pPin) 



BvLevelJ 



PreaVirHane* - 

Volw 



•f 4 FroqlnCom* 4 BlockKame$ 

- »t» 4 VoXuuIoCoo$ * BlocJdflame* 



DeciareA*, DeelareB*, Process*, Init$, end Process C ere linee of 
C oode tih-at. vrtll fee past«d iafce fcbs DepMaln.c file, i-e. th«5« 
seringa must be valid C code. These declere strings will be the, 
declaration statesneats in the Dspfttain.c file that declare the 
variable names associated with this iutuce. 



2505 



[ 



DaelareA* - -CSinGen ' a BlockSaae* 4 » 
Declares* • "doer - -4 Freqvaxtfanot a ■ 
Declare C$ • 'float » 4 Volume VarJtana* a 



m m m 



a PropFout* a * 
a PropVoutS a 



ia the particular fxeewvork that this eoBponent was designed for, 
each block mist sioporc en XVZT function and a PROCESS function - 
The in it function perform* any naeessery initialisation functions . 
The process function will be called Cox each data aampls, at the 
sample-rate interval. The process function provides ell mathematical 
or logical op«rtion* chat ere to be applied to each sample , in 
this case, the process function calculates ths next discrete value 
of the wave. 



2506 



C 



Xnltfi - "SinCen_Iait <*» a BlocaMaise* a • a PropFout* 4 », freqsempling) 
Process* • H Sia0en_ProceeB (4» 4 BlorkWameS 4 V • 4 rrecVaxllaeeS 4 ", 4* 4 Vout* 6 
PreceseAS - Veajt$ a m *• • a VoluaeVarSana* 4 • ; " 



The AddPragment function below will place the lines of code that 
were put -together above into DspHatn.c file, in the appr opriate sections . 
ats below correspond to Comments in the cspaain.c file. 



2507 



FCM_AddFi 

PCM AddPra; 



PKJjbs t Fragment Map IpProj ect ) 

t pprssosatiep, pThia&lodc, -include-, "SinGea.h" 

,t prreomentMap , pThisBlock, "Inif , Init* 

ppragraentKap pTbiaBlocX, "Declare" , Declare** 

FGM_JUldTragment p Fragment Map , pThisBlocx. "Declare", DeclareBS 

FCM_AddPragment pPragmentNap , pThisBlocx, "Declare", DeclareCS 

PCM^AddFragment ppngeencHap, pTbiefiloclt. "Process", Process* 

FGW_AddFragmcnt p Fragment Map, pTbiaBlocX. "Process". Process AS 

{ 



•Line A 

B 
C 

•Line D 
• Line E 
r 

G 



End Punetion 



of File 



FIG. 171 
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Listing of DspMoin.c : (begin Fig 17 J) 



2601 



2602 



/* DspMain.e •/ 



r #i 



«includ« "flfcdAfx-h" 

#i_nclude -Aic.h- 

t Include -siaoen.n* 

iinclud* "Daprtain.h' 



/•Wire Definitions */ 
float CReq ; 
float SOI ; 
float S02 ; 
float S03 ; 



2600 



/* alMy* included by Ttbio •/ 

/* SZCn. end SX92 Liu« A ♦/ 
/• hwuUr file Cor drawing */ 



/• Aiclaput is always required */ 



2603 



/ "Ccapancat XAttancM*/ 

CSinGen SI HI ; 

float CirreqSZNl - 200 ; 

float fZVolUMSXMl - 0.4 

CSi&Gen SI HQ ; 

float «Preq5XW2 • 200. ; 

float fXVoluBeSXK2 • 0.4 



2604 



i: 



void OnCrtabi (float treoSeaipling) 



SinGen_Xni,t (tSXNl. 440, fraajSampliag) 
fiiaO«n~Iiiat (&SXV2, 201, t x^qSatapling) 



void ooproees* (Cloat f reqsanpJLing) 

2605 ! SinGcn Procese IfcSXVl, fXPreaSnn., fcfioi) 
SOI *» fXVoiuneSZttl ; 

£lnO*n_ProcreaB (6BXV2, £XPreq8XN2, 6002) 
j SO 3 *• £ZVolUBeSZH2 ; 

505 - SOI ♦ 902 f 
AlcOucpuC (S03> ; 



/* EIH1 Line C 
/* SIHl Liar D 
/♦ SUTl Line B 
/♦ SXH2 Line C 
/• sua Line D 
/• 8ZS2 Line B 



SHU Line 



*/ 
*/ 
•/ 
•/ 
*/ 
*/ 



Sim. Line P */ 

Sm Line G */ 

AZH2 Line P V 

SXB3 Line C ♦ / 

ALU! OnAaaontbla acript •/ 

DAC QoAsseotble script •/ 



of Pile 



FIG. 17J 
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2700 



(Jompontrnt Gulieiv 




Add 



^ J 



FIG. 18 



Screen shot of component gallery. 
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FRAMEWORK RULES FOR BLOCKS 



2800 



Rule Number 


Rule Definition j 


B0O0 


Every block most have a "project" attribute 


B001 


Every block's project attribute must have same value 


B002 


Every block must have a unique instance name 


B003 


All block properties must be within allowable rnax-rnin range 



FIG. 19A 



2900 



Framework Rule HOOD ; Every block oust. hav* a -project- attribute . 

Function CbeckJtule_»DOO (pProjeet) a* Long 

Function return* true la all block* in project 
have a "project attribute. 

Din NufnberOfBl ocX* In Project as Long 
Dim iBlock M Iiosg 
Die Resale as Long 



Result t 

SuaberOCBlocJurZnPro j eot 



For iBlock 



(pProject) 
0 To NunberCeSlockalnProject - 1 



If Not Ver±ryJUttrlfeut«2x±ete U&loek, •Project-) men 
Result - False 



Next: IB lock. 

ChBckJtule^BOoo ■ Result . 
find Function 



1 2901 | 
} 2902 | 
1 2903 | 



FIG. 19B 
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3000 





* Check all Block Rule* 


Sub CheckBlocfcRules (pProj e cx) 






Din Result as Lang 






Result » CneakRule_B0O0(pPxejeet) 
l£ WOT RnfluXt TK«n MBofeox *W«uingT 


Rule violation: 


BOO0* 


Result ■ CheckRule_B00l (pProject) 
If MOT Result Thexf"M»9box "Warning : 

• I 

Result, - GheckRule_B002 (pProject) 
If WOT Result Then Magbox •WimUig: 


Rule violation: 


B0D1" 


Rule violation: 


B002- 


Result ■ CheckRul»JB003 (pProject) 
t£ If OT Result Then Ha^booc 'Nuningi 


Rule violation: 


B003- 


End S ub 








FIG. 19C 
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* Code for a simple Framework 


This fneewtk checks rule* fcfest 
workspace*, projects, blocks, ax 


pertain to 

id wires. 





p workspace is a pointer to a workspace 
pproject is a pointer to a. project 



CheokWorkSpaceRules pWorkarpace 
Checkpro j ectRul es pproj e>ct 
CheckBlockRule e p*r©j set 

CheckMireRules ppro j set 



PIG. 19D 
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3100 



Workspace 



109 



Project: A 109 



General 



Processor: A 



109 



Workspace Rules 



Project Rules 



Wire Rules 



Block Ruies 



109 



109 
109 
109 
109 



Platform: A 



RTOS: A 



109 



I/O Rules 



Memory Rules 



109 



Problem Domain: A 



ScneOuling Rules 



109 
109 

\ 09 



Resource Rules ^ 1 09 



109 



Data Flow Rules 



Convention Rules 



109 
109 



FIG. 19E 



Illustration of a framework hierarchy 
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3200 




FIG. 20 A 



Block diagram of the component publisher. 
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3300 



I DSP Cainpiment Publi'hei 


CGTOoncrt ) Vendor) irtmt mem \ Prapecfe* | Ream* | 

GUIO: J{2D2mD8CK87DC-11D2«l35«600892CD7O 
Name. jSrfien 






1 

SinGen 

loo 11 


Ubt* | 

Detopten: |Sirw Gtncrator 


1 









FIG. 2QB 
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3400 



DSP Cnmponcnl Publisher 



CotBpow cn t Vendor* Hi 



Vendor Km«c 




VandofDcJcnpnofr -|Texa* lnrturaer* Corporation 






4$ <fi** \ m«*> i 


EH* 





FIG.20C 
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3500 



DSP Lomnuncnt Publiohcf 



Hnterfaoe*- 



B-& Output Signal 
j EhK VoU 

B-©S Input Event 

IFreq 
I Woktrm 
i-$9 OUtxJt Ev«n» 








<fiaek | 







FIG. ZOD 
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3600 



DSP Component Publisher 



Qw^antnt | Vindorj tr**f*cet Prcpeto | fi^oucw ) 

_ - ; -» - - 

~ * lopp ro w ^ 1 fi. ^/.»\ rr .- .... 

fi^nSBBBDHT 

M* Uabd 









Uwt> | fHsh | Coned ( 



FIG. 2Q£ 
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3700 



D5I 1 Component Hubfi^hci 











Uxtpormt | Vendor I'Tntortec 


*s| Prop 


#:, 


•*? 






















Feedback, obj 








Imaga3&ipg 




















MatKh 










OMttamblaTSL 










QnDapotitTSL 










OnPrepwty.TSL 










SWaanc 










ShSonh 










SMcnobi 






* 




tiDQeSOLbflnp 









■ Bp** 1 

"^^^T 'I - SSI 

I fl«™" if 
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3600 



rk Rule PO03 : Every pis ouit nave a unique name. 



Function CaeckRUle_PQ03 (pCxsmpaacntinPuhlioher) as boo? 

Function return* true is all pin* on a block 
or on * cc*T*pon**ifc h»ve a unique name. 

Dim HumberofFina a* Long 
Dim ipin a* Long 

Dim pPin «.« Long 
Din iTaatPin a* 1*009 
Din pTaacPin a* Long 
Dim Aaault a* Uang 
Din TawpMame a* String 



Rasult - Trtxa 

NuabarOfPin* • OnjectGetNUmPina (pCooiponantZnPublivher) /~ 

For ipin «■ 0 To NumbarOfPina - 1 _ ' 

pPin - C*tL PiA»y index: (iFia> — *— 

TenpName - CefcPinNane Ippin) 

For iTaacPin m ttumbarotPIn* - l To iPin + 1 Step -1 

pTestPin * OatPinBylndAx(iTaiCPin) 
If (Tanptlane - OatP a nnaw e (pr*atpin> } men 
awult m Pal aa 
Exit Tor 
2nd zf 

Sext itaatpin 
If WOT Batult Than Exit Fox 
Ksgbojc »E>uplieata pins named: * 4 
tnext ipin 

ChecKKule_PQC3 • Result 
Bnd Function 



3801 



3803 



FIG. 21 



( Component Publisher uses Framework to verify component meets FW rules. 
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3900 



39D1 I 



. V/inApu - Miciasoft Developer Studio - [C \1 ATtbioNEKainplcsUMmUibJ 




F1G.22A 



Shows a probe. 
Shows a COM block. 

Shows. Tibio running in Microsoft Dcv Studio (ska Visual Studio) 
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FIG. 22C 106 



Screen shot of viewer in spectrum analyzer mode. 
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4000 



Tbe Autofefaae function in called to create n unique block 
instance un. 



Puncrtioa AatoMi 



4001 



D is RuneiodcB 
Dim pBlock 
Dim pDxmving As Long 
Din pTblaRlfVTk As Lang 
Dim ThiMald As String 

Dim Cosp« . As Long 

Dis j 



tlihortsueS) A« Stria? 
As tioog 




pDrsviag - TSJ*_GetT3iimX>r Awing 
NusBlocke . DIW_OsUtusBloc)cs<pDrswixig) 
pThisBloc* - TSLjestttaOsBloek — 
ThJ.«Ouid • PXiK^QstCCSjpcnsntOPID (pTtaigBXocX) 
• 0 



4005 



4006 



For J «* o To wusBlocki-i 

pBlock • DRW_C«tBlockS3rIjMUx(pmr«wiBg t j ) — — 
If ThisOuid - BXJCJ0stCoaipos««t0TTn>(p6lock) Then 

Coops m Ccsps ♦ 1 
tod X* 



4002 
4003 
4004 



| 4007 | 
| 4008 1 



AutoSSM * ihorcuste^ * St r< Coup*) 
End Function 



FIG.?* 

25 
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1401 



1404 



Slider 


1407 


Component 


fcventc 





Shared 



1405 



1403 

fcvents 



o 



Gain Control 
Component 



Proxy 



Stab 



FIG.Z5A 



Passing events via. shared memory. 
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/* Fiaxy code for tending three output cvcsttt using i hired mem 


ory •/ 


void Control Ob j ac tX (int a, int b, int c) 

{ 

cfear • p»ux £er * OeXBuffer () ; 
Putlut (pBuffer. a) ; 
Put Int (pBuff «, b) ; 
SUltlnt (pBu££«, C> ; 






FIG. 25B 


/* Stub code for receiving three input events using thared men 


wry*/ 


void »tubOa»trolObjectX () 
( 

char * p»uf£er > OetBuffer O ; 
1st a « Getlnt (pButfcr) ; 
int b ■ Get Int (pBu££«r) ; 
int c • Getlnt <pBu££ar) -. 






Ccmtre olObj octX (a, b, c) ; 

) 





FIG. 25C 
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1401 w&« 



Sitter 
Component 



Proxy 




Gain Control 
Component 



FIC.25D 

Passing events via a wired connection. 
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/» Proxy code for tending term output wonts using USB channel */ 



void ControlObjoetX (ittt a, lat b. int c> 

( 

char • pBuf f»r * MtBttffer () ; 
Put Pore (pBuffer, •>) ; 
Put Port (pBuffex. b) ; 
PutPort <pBtttf#r, c> ; 

) 



FIG. 25E 



P Stub code for receiving three input events using USB channel */ 

raiA »trubControXObj*ctX (J 

( 

char * pftuffmr - OofctuXter () ; 
int * - O^tPort <pBu««r) 3 
Int b - Get Pore (pBuffer) ; 
1st c a CetPort (pBuCfnr) : 

CantrolOb j oetX (a, b r e) ; 



FIG- 25F 
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